Systems, applications and products in data processing for credit check

ABSTRACT

A system, application and product in data processing is disclosed for setting up a credit check of a customer. A customer risk category is set. A credit is reviewed based on the risk category. A customer hierarchy is set. A customer credit limit is assigned to the customer based on the reviewed credit and the customer hierarchy.

REFERENCE TO EARLIER FILED APPLICATION

The present application claims the benefit of U.S. ProvisionalApplication Nos. 60/800,763, 60/800,780, 60/800,779, 60/800,767,60/800,766 and 60/800,765, filed May 15, 2006, which are incorporated byreference herein.

BACKGROUND

Software solutions may be used to help move companies toward betterbusiness practices, such as around order fulfillment, supply chainoperations, inventory management, product pricing and global commerce.The solutions may help fast-growing companies decrease the amount oftime it takes to establish new business capabilities by focusing onimplementing those capabilities that provide the most business impactwhile making judicious, prudent use of capital. The solutions mayprovide proven business design alternatives that address variousspecific needs allowing the solution to be as unique as the business.With such solutions, executives or others at the companies may weighpriorities, tradeoffs and the effort required to produce the desiredresults, efficiently and directly as well as mitigate the implementationrisk.

BRIEF SUMMARY

A system, application and product in data processing is disclosed forsetting up a credit check of a customer. A customer risk category isset. A credit is reviewed based on the risk category. A customerhierarchy is set. A customer credit limit is assigned to the customerbased on the reviewed credit and the customer hierarchy.

These and other features and advantages of the invention will becomeapparent upon review of the following detailed description of thepresently preferred embodiments of the invention, taken in conjunctionwith the appended drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of an exemplary database structure for storingcustomer related information.

FIG. 2 is a flowchart of an exemplary entering of data.

FIG. 3 is a block diagram of an exemplary ship-to partner function whichincludes a sub-set of the information of FIG. 2.

FIG. 4 is a block diagram showing an exemplary setup procedure for aone-time customer.

FIG. 5 is a block diagram of an exemplary general computer system.

FIG. 6 is a copy of an exemplary commercial invoice.

FIG. 7 is a copy of an exemplary content list manifest.

FIG. 8 is a copy of a second page of the exemplary content list manifestof FIG. 7.

FIG. 9 is a flowchart of an exemplary cross-dock procedure.

FIG. 10 is a flowchart illustrating a process for credit checking.

FIG. 11 is a flowchart illustrating a two-level credit check for a payerand central office.

FIG. 12 is a flowchart illustrating an exemplary credit check for a newcustomer.

FIG. 14 is a block diagram showing a process for partner determination.

FIG. 15 is a block diagram of an exemplary sales document header.

FIG. 16 is a flowchart illustrating partner determination for a customermaster.

FIG. 17 is a flowchart illustrating partner determination for a salesdocument header.

FIG. 18 is a flowchart illustrating a potential process for intercompanypricing.

DETAILED DESCRIPTION

The following relates to systems, applications and products in dataprocessing, such as with respect to end customers, credit check, crossdocking, expedited orders, inter-company pricing, and partnerdetermination.

End Customer

1. Create/Maintain Master Data—Customers

FIG. 1 is a block diagram of an exemplary database structure 100 forstoring customer related information. The structure 100 may include amodule 110 and sub-modules 120 for storing information related to salesand sales distribution. The structure may include a setup of a customermaster record. The customer master record may be used in the creation ofsales documents, deliveries, and billings, as well as for reporting andother activities. The customer master records may be created forspecific purposes or functions, e.g., a Sold-To, a Bill-To, Ship-To,Payer, etc. Once the master records are established, customer accountscan be linked together to reflect the structure of the customer, e.g.multiple ship-to's can be linked to a sold-to, and they can also behierarchically linked to establish account group relationships betweensold-to's and central offices, as well as central offices to world-wideaccounts.

In the semiconductor industry, for example with regard to semiconductorcompanies, partner functions may be set up first as a sold-to customerand then as proceeding partner functions. While this may ensurecontinuity in the data, it has the potential to overload the system withirrelevant information. To try to avoid overload, only the partnerfunctions that are needed be set up in the system may be used. Whencreating a customer record, certain data fields may be mandatory input,others may be optional, and still others may be for display onlydepending on the customer account type used, such as sold-to, ship-to,bill-to, etc.

The following is an example of the setup of the different usages, e.g.,account types, of customer records for the different types of customers.For process architecture elements, an audience may include creditmanager, customer setup, and customer service. Customer master data mayinclude information required by the system to set up a new tradingpartner, e.g., customer, or maintain an existing trading partner withany of the customer usages of sold-to, ship-to, bill-to, payer, centraloffice, worldwide account, field sales assistant, or sales office.

When creating a new customer account, a common set of customer usagesare those associated with a sold-to account which provides automaticadditional usage as a ship-to, bill-to, and payer. The stages of setupmay include views for address, communications, tax, delivery times,payment, sales, delivery, billing, document creation, and linkage toother associated customer numbers, such as ship-to's, etc. Once thecustomer is setup, credit limits may be added in a separate series ofsteps, which may include the setting of a credit risk category andconfirmation of a credit review date. After credit has been established,the customer account may be activated for sales document processing.

Master records may be divided into the following areas so that eachcompany code and each sales organization can store its own informationfor doing business with customers. General data 130 may be data thatapplies to every sales organization in the company. The general data 130includes, for example, the customer's name, address, language, andtelephone data. Company code data 140 may be data that is specific to anindividual company code. Company code data 140 may include, for example,the reconciliation account number, terms of payment, and dunningprocedure. Sales area data 150 may be data relevant to the salesorganizations and distribution channels of the company. Data that isstored in this area may include, for example, data on order processing,shipping, and billing.

FIG. 2 is a flowchart of an exemplary way of entering of data. At block200, a customer file of customer data may be created. At block 210,general data, such as the general data 130, may be entered as part ofthe customer data. At block 220, company data, such as the company data140, may be entered. At block 230, sales area data, such as sales areadata 150, may be entered. At block 240, the customer data may be saved.At block 250, the customer data may be linked to a customer hierarchy.At block 260, credit data may be set. The system may provide separatefunctions for maintaining master records, depending on how they areorganized. Master records may be maintained centrally for all areas orseparately, such as for financial accounting, and sales anddistribution. The system may track the end customer when a distributoracts as an intermediary for the industry to understand the clientmarket.

Data for business processes and roles/responsibilities of the system mayinclude Company Code, Sales Organization, Usage of the account, Address,Tax ID, Payment Terms, Sales, Pricing Terms, Billing Terms, Documentsrequired, and other account partner functions such as central officenumber and world wide account number, or other number used in creditmanagement. After execution, the data may result in a complete customeraccount being set up in the system and subsequently activated.

To understand concepts in a business case, the following scripts may beexecuted in sequence, if necessary. A customer sold-to may be created asthe partner function to which all others are connected. The customersold-to script may represent what most people perceive as the truecustomer. The sold-to may then be connected to the sales hierarchy. Thebelow steps may be used to fully populate a sold to partner. Theinformation may be separated by general, company code, and sales area.The following account types may be used to create each trade partner:Domestic and International Account type; 0001 Inter-company Accounttype; INT Division/Distribution Channel: 50/50; and One Time CustomerAccount type: CPD (note: address information is not required).

Referring also to FIG. 1, regarding the General Data 130, an addressview tab 160 may include, name, search term, street, city, zip code,country, region and language. The name may be a required input. This mayinclude a customer name that will appear on all correspondences with thecustomer. Configuration of the field may not be required, such as byusing standard functionality of an SAP architecture. One configurationmay be suitable for all applications. The search term may be a requiredinput. The search term field may assist the user in finding a customernumber when the customer does not know the customer number. The searchterm field may be used to search for a group of customers that have thesearch term. For example, if search term equals INTEL is set, a list ofall customers containing INTEL may be used. Additional configuration maynot be required, such as with the SAP architecture. The street may be arequired input. This may be the address for the customer that beingdealt with.

The address may include the company's headquarters address but may beanother address, such as subsidiary or home addresses. The city may be arequired input. This may include the customer's city. This address maybe used when communicating with the customer. Configuration may not berequired. The zip/postal code may be a required input for mostcountries. The zip/postal code may be configurable to identify how longthe postal code is and if it is required. This may be configurable asGlobal Settings−>Setting countries−>Set country-specific checks. Thecountry may be a required input. This may include the customer's countrycode. The list may include the (International Standards Organization)ISO country code list. The list may be supplied with a basic SAParchitecture configuration. The region may include a state, prefecture,e.g. the state code in the US. A configuration path may include GlobalSettings−>Settings countries−>Insert regions. The language may be arequired input. This may include the language that the customercorresponds in. The list may include the ISO language code list. Thelist may be supplied with the basic SAP configuration.

Regarding control data 162, tax code information, such as regarding thecontrol number, may be used for reporting to the Internal RevenueService (IRS). If the customer is also a vendor, the user may includethe vendor number to offset open items against each other during thepayment process. This is explained more in detail in the accountsreceivable area. Regarding the fiscal address, the customer number maybe included which contains the official address for tax purposes. Thecountry code may include the ISO country code. The transport zone, thezone within a country that determines how a product is shipped to thecustomer may be a required input. For example, in the US, the transportzone may relate to the zip code. The whole route and transportationdetermination process may be documented in a process reference document1045 to maintain route definition and determination in sales orders andtransport orders.

Regarding payment transactions 164, the country may be an optional inputon this screen. A key may be used for the country in which the bank islocated. An option bank key of the customer may be used in case thecompany and the customer handle payments electronically. The bank tabmay be configured as Financial Accounting−>Bank Accounting−>BankAccounts−>Define house banks. An optional bank account input may beincluded. After the user has saved the customer master record, the usermay re-enter through the change mode and add the bank account number inthis field. The bank account number may be identical to the internallygenerated customer number that was entered after the user saves thecustomer master record.

Regarding marketing 166, the legal status may be a required input forinter-company files but optional for others. The marketing field maycontain values such as OEM, Government, Inter-company, Subcontractor,etc. The Marketing field may primarily be used for reporting purposes.Marketing field codes can be configured at Sales andDistribution−>Master data−>Businesspartners−>Customers−>Marketing−>Define legal statuses.

Other tabs in the General Data 130 may be included such as an unloadingpoints tab. The unloading points tab may include a customer factorycalendar field. This field may specify the calendar when the customer isworking. The field may help in determining when a customer can receivethe product. The user may specify in the calendar that the customerworks Monday through Friday and specify when they are on holiday. Thecalendars may be configured at Sales and Distribution−>Masterdata−>Business partners−>Customers−>Shipping−>Define customer calendars.Receiving hours for goods may be input to specify the times, such as inhours, when the customer accepts goods at their location. These fieldsmay be configurable at Sales and Distribution−>Master data−>Businesspartners−>Customers−>Shipping−>Define goods receiving hours.

Other tabs may include a foreign trade tab. Date fields may be used forexport control. The date fields may include the last date a customer waschecked against specified tables, e.g., the table of denial orders. Ifthe flag is set on the date then the customer was found on the table. Inaddition, information about a contact person may be stored. A departmentfield may be used when contact persons are used. This may be thedepartment that the contact person works in. A configuration may includeSales and Distribution−>Master data−>Business partners−>Contactperson−>Define standard departments. Also, a function field may be usedto indicate the function that the contact person holds within thedepartment. The configuration may include Sales and Distribution−>Masterdata−>Business partners−>Contact person−>Define contact personfunctions. Partner details may also be available for input.

Regarding Company Code Data 140, an account management field 170 mayrelate to accounts receivable. A reconciliation account field may beused to specify a general ledger account for posting. A configurationmay include Financial Accounting−>Accounts Receivable and AccountsPayable−>Business Transactions−>Down Payment Received−>Definereconciliation accounts for customer down payments. Sort key may beincluded to specify a layout rule for allocation of the line item. Theconfiguration may be included at Financial Accounting−>General LedgerAccounting−>G/L Accounts−>Line Items−>Line Item Display−>Determinestandard sorting for line items.

A payment transaction tab 172 may deal with accounts receivable,financial accounting and billings. Payment terms may by specified interms of payment with a user's customer. The configuration may beincluded at Financial Accounting−>Accounts Receivable and AccountsPayable−>Business Transactions−>Incoming Invoices/Credit Memos−>Maintainterms of payment. A tolerance group field may be used to allow the userto group customers together in order to handle processing of paymentdifferences. The configuration may be included at FinancialAccounting−>Accounts Receivable and Accounts Payable−>BusinessTransactions−>Incoming Payments−>Manual Payment Receipt−>DefineTolerances (Customers). Terms of payment for bill of exchange may alsobe included at the same place of configuration as the payment terms. Alockbox field may be used by the Accounts Receivable (AR) module, suchas for financial transactions using a secure account. The configurationmay be included at Financial Accounting−>Bank Accounting−>BankAccounts−>Define lockbox accounts at house banks.

For the Sales Area Data 150, a sales tab 180 may be included. The salestab 180 may include a currency field that the customer processes theirin documents. This may include the default currency for all documents.The configuration may be included at Global Settings−>Currencies−>Checkcurrency codes. Also included in the sales tab 180 may be an exchangerate type which may include a Company X standard rate, or a specificrate agreed with the customer. For a specific customer rate, a new keymay be used for the identification of the record. A sales district fieldmay be contained in a field sales office code (FSO). A configuration maybe included at Sales and Distribution−>Master data−>Businesspartners−>Customers−>Sales−>Define sales districts. Sales office andsales group fields may contain the current area/region/district codes.These fields may be configured in Enterprise Structure−>MaintainStructure−>Definition−>Sales and Distribution−>Maintain sales office orMaintain sales group. The configuration may identify the values.

A next step may be to identify the sales office to a particular salesarea and to identify the sales group to a particular sales office. Thismay be configured as Enterprise Structure−>MaintainStructure−>Assignment−>Sales and Distribution−>Assign sales office tosales area or Assign sales group to sales office. A customer group fieldmay be used by Europe to determine the commissionaire country. Thisfield may be configured at Sales and Distribution−>Master data−>Businesspartners−>Customers−>Sales−>Define customer groups. A customer pricingprocedure field may be used to define which pricing procedure the systemcan use when the user creates a sales document. The configuration may beincluded at Sales and Distribution−>Basic functions−>Pricing−>Pricingcontrol−>Define and assign pricing procedures−>Define CustomerDetermination Procedure. However, pricing business rules may be reviewedbefore making the change on the customer.

In the semiconductor industry, inter-company pricing includes a separatepricing procedure which is specific to region and division. Theprocedures may vary in the way that they recover costs. This means thatthe same part may include a different cost when coming from twodifferent locations. This is so the holding plant can recover anyadditional costs associated to the material. A price group field may aidin applying conditions during pricing. This field may be configured as aregion code so that the user can set prices by region if the pricecondition uses the price group. The configuration may be included atSales and Distribution−>Basic functions−>Pricing−>Maintainprice-relevant master data fields−>Define pricing groups for customers.A price list type field may define a price list type to apply conditionsduring pricing or generating statistics. The configuration may be atSales and Distribution−>Basic Functions−>Pricing−>Maintainprice-relevant master data fields−>Define Price List Types forCustomers. A customer statistics group field may be used to aid indefining a grouping for statistics reporting in the Sales InformationSystem (SIS) part of the SAP system. The configuration may be includedat Logistics General−>Logistics Information System−>Logistics DataWarehouse−>Updating−>Updating Control−>Settings: Sales−>StatisticsGroups−>Maintain statistics groups for customers.

With regard to the Shipping Tab 182, a delivery priority field may berequired. The field may set default delivery priority for shippingpurposes, such as in the case of military orders. The configuration maybe included at Sales and Distribution−>Master data−>Businesspartners−>Customers−>Shipping−>Define delivery priorities. A shippingconditions field may be used to define how the product is shipped, e.g.,by air, by sea, by surface, etc. A process reference document maymaintain route definition and determination in sales orders andtransport orders to include more information. The configuration may beincluded at Sales and Distribution−>Shipping−>Basic shippingfunctions−>Shipping Point Determination−>Define shipping conditions. Adelivering plant field may include the default plant from the materialmaster which Company X sends the product from. The configuration may beincluded at Enterprise Structure−>Maintain Structure−>Assignment−>Salesand Distribution−>Assign plant to sales organization and distributionchannel. A partial Delivery/Item field may determine if the customerallows partial deliveries or not, and if so, how many deliveries perline item.

At a billing tab 184, a billing schedule may specify the days the usermay bill the customer. For example, the customer may want all invoicesto be consolidated and sent to them once a week. The configuration maybe included at Sales and Distribution−>Master data−>Businesspartners−>Customers−>Billing document−>Define billing schedule. Aninvoice list schedule may specify the customer's factory schedule toprocess invoice lists. The configuration may be the same place as thecustomer factory schedule listed above. An incoterms one field mayspecify the procedure between the shipper and the receiving party of theshipping costs, e.g., FOB, FOD, etc. The configuration may be includedat Sales and Distribution−>Master data−>Businesspartners−>Customers−>Billing document−>Define Incoterms. An incotermstwo field may represent the shipping point for the material. Paymentterms payment terms for the freight charges. The configuration may beincluded at Financial Accounting−>Accounts Receivable and AccountsPayable−>Business Transactions−>Incoming Invoices/Credit Memos−>Maintainterms of payment. A credit control area may allow the user to set creditlimits. An account assignment group field may be posted for theprocessing of a sales document. The configuration may be included atSales and Distribution−>Basic functions−>Account assignment−>Revenueaccount determination−>Check master data relevant for accountassignment. A tax code may be entered for each of the countries that areset up to receive products from the sales organization of the customer.The configuration may be included at Sales and Distribution−>Basicfunctions−>Taxes−>Define tax determination rules.

An output type field may include data for printing documents. The outputtype may determine when during the sales process that a printed documentis created. A transmission medium may specify how the output shouldgenerated, e.g., as a paper copy, through edi, a fax, etc. The send timefield may specify when the output is created, e.g., during the nextbatch run, immediately, etc. This data may be filled in completely whenthe customer people add a new customer. The default settings may be usedin order to maintain the same output for all customers.

The Partner Functions Tab 186 may represent a customer hierarchy. If theuser is adding a sold-to customer, the screen may allow the user todefine the ship-to, payer, ship-to party etc. The user may also defineother partners that are associated to the customer and to the user'scompany. The carrier or forwarding agent may be defined at this tab. Thefield sales assistant and field sales reps may also be defined here. Apartner function label may represent the type of usage for the customercode. The label may also represent the internal people/group that workwith the customer. The configuration may be included at Sales andDistribution−>Master data−>Business partners−>Customers−>Customerhierarchy−>Set partner determination for hierarchy categories.

FIG. 3 is a block diagram of an exemplary ship-to partner functionstructure 300 which includes a sub-set of the information of FIG. 2. Theship-to partner function 300 may include ship-to, bill-to, and payerinformation, without requiring all the fields of the data structure 100.Other partner functions may be included as a subset of the sold-toinformation although alternate partner functions can be added to asold-to which may have different properties. The shorter ship-to partnerfunction structure 300 may be used, for example, to store informationfor one-time customers.

FIG. 4 is a block diagram showing an exemplary setup procedure 400 for aone-time customer. In SAP, a one time customer may be one with which along-time relationship does not exist. For this case, no customer masterrecord needs to unnecessarily take up database storage. Therefore, acollective master record may be used. A collective master record may bea dummy record which stores data that may identical to a certain groupof customers. The master record may store all one-time customers of thesame region using the same currency and same language. During the salesorder processing, such as using the collective master record number asthe sold-to, the user may enter the data specific to the customer notstored in the collective master record, such as the address.

At block 410, the user may create a one-time customer record. At block420, the user may assign a credit account to the customer. At block 430,the user may set the customer's credit limits. At block 440, the usermay set the customer's risk category. At block 450, the user may set adate of internal review At block 460, the user may create an order forthe one-time, or less frequently used, customer. With the customermaster with reference it may be possible to create a customer using anexisting customer as a model. A combination of Customer number, CompanyCode, Sales Organization, Distribution Channel, or reference divisionmay be used to automatically populate the new record. The createdcustomer may hold all the same characteristics and partner associationsthat the referenced customer holds. While creating the customer, fieldsmay be modified to give the master record different characteristics.

In the semiconductor industry, an additional partner function may becreated at other semiconductor companies to help track distributorsales. A partner function of EC (End Customer) may be created using theaccount group as a model. Additional fields may then be added to thebase SAP screens to hold customer numbers that are specially stored onthe sales orders that are sent from the distributors. A prearrangedagreement may be met with the distributors to have them populate thatcustomer information of who they are selling the products to in theorders when they are placed. Through customer code, this information maybe stored in SAP and may be assigned to the proper Customer Hierarchy toallow beneficial pricing, such as based on end customer, to be leveragedby the distributors.

Internal customers may be set up using the plant information already inthe system. In order for the different plants to transfer materialbetween themselves, the locations may be set up as a customer. Thecustomer may be created using an internal account group, such as ZINT,and may be assigned to the company code level to allow for crossorganization transfers. The record may only require the Name, Searchterm, Address, Rec. Account, and Sort Key.

FIG. 5 is a block diagram of an exemplary general computer system 500that may be used with to implement the above embodiment and one or moreof the below embodiments.

The computer system 500 may include a set of instructions that can beexecuted to cause the computer system 500 to perform any one or more ofthe methods or computer based functions disclosed herein. The computersystem 500 may operate as a standalone device or may be connected, e.g.,using a network, to other computer systems or peripheral devices. Thetool may be implemented hardware, software or firmware, or anycombination thereof. Alternative software implementations may be usedincluding, but not limited to, distributed processing orcomponent/object distributed processing, parallel processing, or virtualmachine processing may also be constructed to implement the toolsdescribed herein.

In a networked deployment, the computer system 500 may operate in thecapacity of a server or as a client user computer in a server-clientuser network environment, or as a peer computer system in a peer-to-peer(or distributed) network environment. The computer system 500 may alsobe implemented as or incorporated into various devices, such as apersonal computer (PC), a tablet PC, a set-top box (STB), a personaldigital assistant (PDA), a mobile device, a palmtop computer, a laptopcomputer, a desktop computer, a communications device, or any othermachine capable of executing a set of instructions (sequential orotherwise) that specify actions to be taken by that machine. Thecomputer system 500 may be implemented using electronic devices thatprovide voice, video or data communication. Further, while a singlecomputer system 500 is illustrated, the term “system” shall also betaken to include any collection of systems or sub-systems thatindividually or jointly execute a set, or multiple sets, of instructionsto perform one or more computer functions.

The computer system 500 may include a processor 502, e.g., a centralprocessing unit (CPU), a graphics processing unit (GPU), or both.Moreover, the computer system 500 may include a main memory 504 and astatic memory 506 that may communicate with each other via a bus 508.The computer system 500 may further include a video display unit 510,such as a liquid crystal display (LCD), an organic light emitting diode(OLED), a flat panel display, a solid state display, or a cathode raytube (CRT). Additionally, the computer system 500 may include an inputdevice 512, such as a keyboard, and a cursor control device 514, such asa mouse. The computer system 500 may also include a disk drive unit 516,a signal generation device 518, such as a speaker or remote control, anda network interface device 520.

The disk drive unit 516 may include a computer-readable medium 522 inwhich one or more sets of instructions 524, e.g. software, may beembedded. Further, the instructions 524 may embody one or more of themethods or logic as described herein. In a particular embodiment, theinstructions 524 may reside completely, or at least partially, withinthe main memory 504, the static memory 506, and/or within the processor502 during execution by the computer system 500. The main memory 504 andthe processor 502 also may include computer-readable media.

Dedicated hardware implementations, such as application specificintegrated circuits, programmable logic arrays and other hardwaredevices, may be constructed to implement one or more of the toolsdescribed herein. Applications that may include the apparatus andsystems of various embodiments may broadly include a variety ofelectronic and computer systems. One or more embodiments describedherein may implement functions using two or more specific interconnectedhardware modules or devices with related control and data signals thatmay be communicated between and through the modules, or as portions ofan application-specific integrated circuit.

The present disclosure contemplates a computer-readable medium thatincludes instructions 524 or receives and executes instructions 524responsive to a propagated signal, so that a device connected to anetwork 526 may communicate voice, video or data over the network 526.Further, the instructions 524 may be transmitted or received over thenetwork 526 via the network interface device 520. While thecomputer-readable medium is shown to be a single medium, the term“computer-readable medium” includes a single medium or multiple media,such as a centralized or distributed database, and/or associated cachesand servers that store one or more sets of instructions. The term“computer-readable medium” also includes any medium that is capable ofstoring, encoding or carrying a set of instructions for execution by aprocessor or that cause a computer system to perform any one or more ofthe methods or operations disclosed herein.

The computer-readable medium may include a solid-state memory such as amemory card or other package that houses one or more non-volatileread-only memories. Further, the computer-readable medium may be arandom access memory or other volatile re-writable memory. Additionally,the computer-readable medium may include a magneto-optical or opticalmedium, such as a disk or tapes or other storage device to capturecarrier wave signals such as a signal communicated over a transmissionmedium. A digital file attachment to an e-mail or other self-containedinformation archive or set of archives may be considered a distributionmedium that is equivalent to a tangible storage medium. Accordingly, thedisclosure is considered to include any one or more of acomputer-readable medium or a distribution medium and other equivalentsand successor media, in which data or instructions may be stored.

Cross-Dock and Direct Shipment

FIG. 6 is a flowchart of an exemplary cross-dock procedure. For the sakeof convenience, the procedure is described in terms of a semiconductorcompany using the cross-dock and direct shipment processes, but theprocedure may be used in other industries as well. The cross-dockprocess may be an extension of the direct ship process and follow thesame processing steps, plus several other steps. Both shipment methodsare discussed along with different aspects of each, both infunctionality and business processing.

A cross-dock shipment may refer to a consolidated shipment made up ofone to many inter-company sales orders, which is taken through customsby a service provider (e.g. FRITZ LOGISTICS), separated at the serviceprovider location, and delivered directly to the customer. Thecross-dock process may be used to reduce freight costs, reduceimportation taxes, and reduce the documentation required for exportprocessing by consolidating shipments, utilizing inter-company pricingduring importation, and breaking them down at a service providerlocation in the destination country.

Direct Ship may be used to describe the shipment of goods directly tothe trade customer against a trade Sales Order. This means that goodsmay be shipped from an A/T directly to a trade. “Direct Ship” may referto either inter- or intracompany sales orders, a difference being therequirement for customs documentation for inter-company shipments. Forexample, a direct shipment might be from an A/T in the U.S. to acustomer location in the U.S. or from an A/T in Germany to a customerlocation in the U.S. In the inter-company example, if there were onlyone or few packages, the freight savings may not justify consolidationand processing at the service provider location, so they are not beingprocessed as a cross dock. In the intra-company example, the shipmentcan be picked, packed and shipped using the same processing as ashipment from a distribution center (DC). Direct shipments may be usedto reduce inventory carrying costs and to meet customer demand.

A difference between a direct ship and a cross-dock shipment may be thatin a cross-dock, the service provider, for example a representative ofthe semiconductor company, may be responsible for passing the itemsthrough customs using inter-company prices on the invoice and thenbreaking down the shipment and shipping them immediately to thecustomer. Inter-company pricing may be used at customs because theshipment is shipping from one company code of the semiconductor companyto another company code of the same worldwide semiconductor company.After passing through customs, however, the shipment may be diverteddirectly to the customer.

In general, overseas cross-company shipments against customer salesorders, whether cross-dock or direct ship, may be processed on anexception basis at the request of the business planner to meet customerdemand. The cross-dock process may utilize highly customizedfunctionality and increased manual steps during the order-to-invoiceprocess compared to standard shipments. Manual processes includemaintenance on the sales order, a custom transaction to consolidateshipments and create the required documentation, and processing at aservice provider location. Still, the cross-dock design may be justifieddue to the freight cost savings and reduced documentation requiredduring customs processing.

Inter-company cross-dock and direct shipments may be processed to shipgoods from between regions without storage at a company facility. Thesemethods may be utilized to meet urgent customer demand and reduceinventory carrying costs. Further, the cross-dock process may reduceimportation costs by using inter-company pricing and reducing freightcosts by consolidating inter-region shipments. The consolidation ofshipments for cross-dock may also reduce the paperwork required forcustoms. Both processes may require additional processing steps anddocumentation on top of the standard order to invoice functionality. Thecross-dock process may require documentation in addition to thedirect-ship process due to the break-bulk that may occur at the serviceprovider location.

The cross-dock shipments may be initiated by the business planner whoidentifies the requirement to ship from an overseas, cross-company codelocation direct to a customer. This requirement might be a result ofstock-outs in the receiving country's distribution centers (DCs) and/orassembly/test (A/Ts) sights, in combination with demand from a valuablecustomer. To process a cross-dock shipment, the order processor maychange the default plant on the order to the new plant in anothercompany code than the company code of the customer. On the order, across dock address partner function may be entered to reflect theservice provider location in the destination country (e.g. FRJTZLOGISTICS—New York Harbor). The partner may not be a true vendor, it mayhave its own account group, but rather a ‘place holder’ for the serviceprovider address that is used by the delivering warehouse to process theorder and output the appropriate documentation.

The order may be processed like any other order in the system whensaved. The system may check availability in overseas plants and createthe delivery on the appropriate delivery creation date. Cross-dockspecific shipping instructions may be provided for the delivering plantvia custom coding in the sales order. The delivery may be picked andpacked at the warehouse according to standard processing. According tobusiness rules, appropriate deliveries may be consolidated into onewaybill. The cross-dock process may require more functionality than thestandard waybill transaction in SAP provides. The standard waybilltransaction may produce a waybill content list for each customer thatsummarizes each delivery, its destination, and the contents.

In waybill processing, each individual delivery may receive its ownstandard trade invoice (F2) created during normal processing as well asthe waybill content list. The F2 invoice may be sent to the customerafter PGI, per SAP processing. During a cross-dock, the waybill contentlist may be included in the shipment to aid the service provider inbreaking down the shipments and forwarding them to the customer. It mayalso be possible to send the waybill content list to the serviceprovider as output of the waybill processing. Some semiconductorcompanies also create manifest shipments, which may consolidate numerouswaybills into one shipment. A custom transaction can be used tofacilitate this process along with a manifest version of the waybillcontent list. Manifest shipments are often used by semiconductorcompanies to further save on freight costs.

Since a cross-dock shipment passes through customs, documentation ispresented to customs containing the pricing for each item in theconsolidated shipment, in addition to the required import/exportinformation. For a cross-dock shipment, this document may be known as aMaster Commercial Invoice. SAP may not support a Master CommercialInvoice for consolidated/waybill shipment, so custom code may berequired. One advantage of a Master Commercial Invoice, which is asingle document containing the pricing for all materials in a shipment,is that it may greatly reduce the documentation required for customsprocessing of a consolidated shipment.

One of the purposes of a cross-dock shipment may be to utilizeinter-company pricing when bringing the shipment through customs. To dothis, the custom Master Commercial Invoice may be designed to display aDC in the receiving country as the Sold-to customer and the ServiceProvider location as the Ship-to location. The Master Commercial Invoicemay display all items in the shipment with the associated inter-companyprice and will not display any customer information. The document may bea combination of a pro-form a invoice and an inter-company invoice. Thedocument may include the characteristics of the pro-form a invoice, suchas no accounting impact and the ability to be created before post goodsissued (PGI), and utilize the pricing procedures applicable for aninter-company invoice (IV).

One option to accomplish the requirements of cross-dock processing maybe to create a custom transaction. Using this transaction, similar tothe standard shipment consolidation/waybill transaction in SAP, anyrequired importation details, such as flight number can be input. Twocross-dock specific documents may be output. One is the MasterCommercial Invoice, which may display inter-company pricing for items inthe shipment and not contain customer information. In addition, a MasterContent List may be output which details the shipment and is used forreceiving verifications, identifying/locating ‘hot’ items, and tofacilitate Customs' clearances. Three addresses are shown on thedocument: the shipping location, which is the supplying Plant; thereceiving location, which is the service provider location, e.g.Semiconductor Company X, c/o Fritz Inc Ltd, Service Provider Address,which is the address entered as the Sold-to; and the theoreticaldestination of the material, which may be a DC in the receiving country,which may be entered as the Ship-to. The material, however, does notever go to this location. The material is re-routed after customs to thecustomer location. This address may be important so that the materialcan be passed through customs using inter-company pricing.

These documents can be sent to the service provider automatically aftersuccessfully processing the custom transaction. Consolidated shipmentsmay fall under one of various categories: they may be a domestic(standard) shipment, a direct shipment to a customer in another companycode, or they are a cross-dock shipment which is shipped to an interimcross-dock facility, such as one manned by a Service Provider (e.g., viaFRITZ-HNL), who will process through Customs on Company X's behalf andforward it to the customer/end-user. If the shipment is sent through thecross-dock, the user may indicate additional information into the customtransaction such as: branding, description, flight details, vendornumber of service provider, and vendor account number of the serviceprovider location. This number may indicate that the goods are to travelthrough that particular entry point for clearing the customs. Each entrypoint may be set up in the system, for example: Company X, Amsterdam C/OKLM Cargo Logistics SPL/CL. This vendor number may also be enteredduring sales order maintenance as a partner function.

FIG. 6 is a copy of an exemplary master commercial invoice, FIG. 7 is acopy of an exemplary master content list manifest and FIG. 8 is a copyof another exemplary master content list manifest. Each individualdelivery may be packed and consolidated into the large shipment. Whenthe shipment is passed to the forwarding agent, the shipment may beaccompanied by the Master Commercial Invoice and Master Content Listthat is used to bring it through customs.

Once the shipment is Post Goods Issued, two standard billing documentsmay be created based on the inter-company sale. The first document maybe a trade invoice (F2) destined for the customer which contains thecustomer pricing. This may be the same invoice the customer would get ifthe materials were sent from the local DC. The customer may need to knowthat the shipment came from another company code or went throughcustoms. Since the F2 invoice is normally created during the firstapplicable billing due list run after the delivery is deposit goodsissued (PGI'd), during a cross-dock the customer could receive the F2well before the goods arrive, since the shipment may travel throughcustoms, gets broken down at the Service Provider, etc. If this isundesirable, some companies may place an F2-specific billing block onthe order, e.g. ‘Transit to Cross Dock’, before it is Post Goods Issued.Once the materials are received at the cross-dock location, the billingblock may be changed to another block, ‘Receipt at Cross Dock’. Afterthe shipment is sent to the customer, the block may be removed and thecustomer billed. This may ensure that the customer does not receive theInvoice for the shipment before the goods are delivered.

The other document produced after PGI may be a standard SAPinter-company invoice (IV). This document may be created to charge theselling sales organization for the goods that they purchased from thedelivering Plant. This document may contain inter-company pricing. Forexample, if an order from the U.S. Sales Organization was maintained toship from a German Plant, the IV invoice may charge the InternalCustomer of the U.S. Sales Organization for the material.

With regard to semiconductors, when the shipment arrives at the customslocation, it may be processed through customs by the Service Provider.The shipment may then be taken to the Service Provider's location. Theshipment may be broken down into individual shipments, each detailed outin the Waybill Content List for the shipment. This document helps theService Provider send each individual shipment to the customer. If abilling block was placed on the customer's order, it may be released atthis time to allow for the Trade Invoice (F2) to be created.

A summary of the documents discussed in the design for the cross-dockshipment process. A waybill content list may be produced after eachapplicable delivery is combined into a waybill for consolidatedshipping. This document may not be used for customs and may containinformation about each delivery that can be used by the serviceprovider, or Forwarding Agent in the case of Direct Ship to break downthe combined shipments and route them to the end customer. A manifestdocument may be created if the company processes Manifest shipments,which are a further consolidation of several Waybills. Thisfunctionality is not standard SAP and may require customization. Ifused, this document may assist the service provider or forwarding agentin break bulk of the combined waybills for onward shipment to the finalcustomer. This document may be output before the items are shipped.

A Master Commercial Invoice (MCI), such as in FIG. 6, may include acustom output resulting from cross-dock specific inputs entered into acustom transaction. This document may be similar to a Pro-Form a invoice(F8) used for customs purposes, as in the Direct Ship process. Thereason a standard pro-form a invoice may not be used during a cross-dockincludes: the invoice document shown to customs for a cross-dock shouldcontain inter-company pricing as a main reason for processing across-dock shipment and reduce import taxes; the documentation shown tocustoms should not include customer information, which is standard on apro-form a invoice; a pro-form a invoice is created based on onedelivery document. On the other had, the Master Commercial Invoice mayshow inter-company pricing for all items in the consolidated shipment(not standard SAP).

Referring to FIGS. 6 and 7, if the company uses manifests, the MCI maycontain pricing for all items in the manifest, rather than just on theWaybill. The Master Content List may include a custom output resultingfrom cross-dock specific inputs entered into a custom transaction. Thisdocument may outline all items in the shipment and may be used to bringthe consolidated shipment through customs. The document may contain theaddresses of the semiconductor locations, rather than the final customership-to locations. The final ship-to locations may be located on theWaybill Content List, which is not used for customs. A Trade/CustomerInvoice (F2) may be automatically generated by the billing due listafter the shipment is Post Goods Issued and sent to the customer. If abilling block is applied, generation of this document may be postponeduntil the shipment is delivered. This document may contain standardpricing for the customer and may be based on the delivery created fromone of the original orders, e.g. it is not a consolidated invoice, sincethe customer does not know or care that the material was shipped fromoverseas. An Inter-company Invoice (IV) document may be automaticallygenerated by the billing due list after the shipment is Post GoodsIssued. This document may charge the selling Sales Organization, usinginter-company prices for the material they bought from the supplyingplant.

A cross-dock process may be an extension of the inter-companydirect-ship process. As a result, the direct ship process may containfewer steps than are required in the cross-dock process. The direct shipprocess discussed may be the inter-company direct ship process, incontrast to a situation where goods are sent from an A/T in one companycode directly to a customer in same company code. In the direct shipprocess, an order may be entered for a customer in one company code witha supplying plant from another company code. This may be termed directship, because rather than entering the standard delivering plant on theorder, then having the delivering plant send a Stock Transport Order(STO) for the goods to the plant in the other company code, the goodsmay be shipped straight from the plant in the alternate company code tothe customer. This may be an exception process and may be used to reduceinventory carrying costs and help meet customer demand.

Similar to cross-dock, the sales order may be maintained to a plant inanother company code. However, no partner function may need to beentered on the order. The cross-dock partner function may be used todesignate the address of the service provider facility for thedelivering plant and to be mapped onto the shipping documentation. Witha direct shipment, the materials may be sent directly through customs tothe customer's ship-to location, so the address is unnecessary.

In the semiconductor industry, when the order is saved, the delivery maybe created according to standard processes. Since there is no partnerfunction on the order, the warehouse knows that the order is directshipped to the customer, rather than consolidated and sent to a serviceprovider. However, according to business rules, if there are otherdeliveries that can be combined onto a waybill and shipped together, thedirect shipments may be consolidated for shipment. Direct shipment,however, does not have to be consolidated and could be a one-offshipment.

If the shipment is not consolidated, a standard pro-form a invoice (F8)may be created before the items are post goods issued. This document maybe manually created. Along with any required customs documentation, thepro-form a invoice may be used by the carrier to bring the goods throughcustoms. The pro-form a invoice and shipping documentation may containthe customer's sold-to and ship-to information.

If the direct shipment is consolidated using a Waybill, a consolidatedpro-form a invoice may be needed to show pricing and contents for allmaterials going through customs. A difference between cross dock anddirect ship may be that the pro-form a invoice, used in contrast to theMCL, contains Trade/Customer pricing since the shipment is clearly goingto the customer. This may result in higher taxes. When the materials arePost Goods Issued, a standard trade invoice (F2) may be created alongwith an inter-company invoice. This process may be similar thecross-dock process since the customer may be billed and the salesorganization selling the material may need to pay the supplying plant.The goods may be taken through customs by the carrier using the tradeprices on the pro-form a invoice. If the shipment was combined into awaybill, it may be broken down and delivered to each customer asrequired. However, this break down does not need to occur at a serviceprovider location. The goods may be received at the customer locationand may never spend any time at the DC.

A summary of the documents used in the design for the Direct shipmentprocess may be as follows. Waybill content list, if applicable, sincenot all direct shipments is combined into a Waybill, may be producedafter each applicable delivery is combined into a waybill forconsolidated shipping. This document may not be used for customs and maycontain information about each delivery that can be used by the serviceprovider, or Forwarding Agent in the case of Direct Ship, to break downthe combined shipments and route them to the end customer. A Pro-form aInvoice (F8) may be created in contrast to the Master Commercial Invoiceused in the cross-dock process. This may be a standard document showingcustomer prices and materials, which may be required for customsprocessing. This document may have no accounting impact and may becreated before PGI so it can be included with the shipment to assist thecarrier in Customs processing. A Trade/Customer Invoice (F2) mayautomatically be generated by the billing due list after the shipment isPost Goods Issued and sent to the customer. If a billing block isapplied, generation of this document may be postponed until the shipmentis delivered. This document may contain standard pricing for thecustomer and may be based on the delivery created from one of theoriginal orders, e.g., not a consolidated invoice, since the customerdoes not know or care that the material was shipped from overseas.Inter-company Invoice (IV) may be automatically generated by the billingdue list after the shipment is Post Goods Issued. This document maycharge the selling Sales Organization, using inter-company prices forthe material they bought from the supplying plant. For intra-companydirect shipments, only the Trade/Customer invoice (F2) may be requiredsince there is neither a customs requirement nor inter-company sale ofgoods.

FIG. 9 is a flowchart illustrating an exemplary cross-dock procedure.The procedure may also be used to create a Manifest shipment if Manifestshipments are used, e.g., for consolidating Waybills. If so, theManifest document may also be created. At block 900, a sales order(VA01) may be created. This transaction may create a new Sales Orderwithout reference to an existing document. At block 910, a sales ordermay be changed. The following data may be entered or changed whencreating or changing a sales order: Sales Area; Customer; Material;Original delivering plant; New delivering plant; Cross-Dock PartnerFunction; Service Provider Vendor Number; Required Customs information,such as Batch Information; Forwarding Agent; Carrier and Flight Number;ECCN and License Information; Delivery numbers for WaybillConsolidation; and Shipping Point of Delivering Plant. Possibleresulting data includes: an Inter-company Order is created; WaybillContent List, Master Content List, and Master Commercial Invoice arecreated and output; Inter-company invoice is automatically created afterPGI and Trade (F2) invoice is created after the billing block isreleased.

After entering the relevant data, the system may generate a Sales Ordernumber. This number may be used in the delivery and shipping documentsin order to quickly reference order information. At blocks 920, 930 and940, if the Business Planner knows that the order is going to be shippedfrom another company code when it is being created, the Plant andPartner Function, e.g., Cross-dock only, may be entered at this time. Ifnot, at block 950, the Plant Partner Function may be entered using thenext transaction. Logistics=>Sales/distribution=>Sales=>Order=>Create(VA01).

At block 952, Delivery Plant at Item Level (VA02) may be created. Thistransaction may also allow the user to change the delivery Plant. Whenthe Plant is changed, the shipping point and route may automaticallychange and the ATP check may run again. The plant change may be dictatedby the Business Planner and performed by the Order Processor. At block954, the delivery may be picked and/or packed.Logistics=>Sales/distribution=>Sales=>Order=>Change (VA02). For crossdock processing, a Partner Function may be added to the Sales Order. Thenew partner identifies the shipment as a cross-dock shipment andidentifies the service provider address for the shipping documentation(MCL and MCI). Logistics=>Sales and distribution=>Sales=>Order=>Change(VA02). A Delivery Note may be created to create an outbound delivery byreferencing the Sales Order Number. The Delivery Note may beautomatically generated. The information entered as part of the SalesOrder may be dropped into the Delivery Note automatically. Pickinginformation may also be entered at this time as can informationregarding shipping and packing. However, shipping and packing data neednot necessarily be entered as they may be entered and updated later. ThePartner Function entered on the order may be copied onto the delivery.The deliver document may be created using a Deliver Due List variantassigned to a Batch Job. Logistics=>Sales anddistribution=>Shipping=>Delivery=>Create (VL01N).

Picking a delivery, e.g., without Warehouse Management System, may allowthe user to change picking options from what was entered in the deliverynote. This process step may allow the quantities picked to be updated,but may not allow the user to specify a particular pick location as thisoption may not be available in a Lean WM system. Logistics=>Sales anddistribution=>Shipping=>Delivery=>Change (VL02N).

Regarding Packing, a Shipment Number/Waybill may be created. This scriptmay create a shipment number in the Transportation module andconsolidate all the given delivery notes. This step may be executed ifthis is the first Shipment Number created for the customer; otherwise,this step may be skipped. A waybill may allow for extra shippinginformation to be added. Logistics=>Sales anddistribution=>Transportation=>Shipment=>Create (VT01N).

Shipment Numbers may be displayed for a customer. This script maydisplay all or any Shipment Numbers for a single customer, which mayhave been created for those that have not been invoiced. This may berequired such that a late Sales Order released Delivery Note may beadded into the same Shipment Number to facilitate waybill shippingconsolidation, finalization and printing. Logistics−>Sales anddistribution=>Transportation=>Shipment=>List=>Planning (VT11).

A delivery may be added to a Shipment. This script describes how to adda delivery note to an existing shipment to facilitate consolidation andprocessing. The shipment cannot have already been scheduled fordelivery. Logistics=>Sales anddistribution=>Transportation=>Shipment=>Change (VT02). For packdeliveries in a Shipment, this script may describe how to consolidateand pack items from multiple delivery notes into the same shippingcontainer. Additional modifications to the Waybill can be made duringthis change transaction. Logistics=>Sales anddistribution=>Transportation=>Shipment=>Change (VT02N). The shippingunits, e.g., cartons, may be Weigh/reweigh shipping units (cartons). Theneed may arise where the shipping containers/cartons are required to beweighed individually for tracking and shipping documentation purposes.The deliveries have already been packed into the appropriate shippingunit. A packing/content list may be output. Logistics=>Sales anddistribution=>Transportation=>Shipment=>Change (VT02N).

At block 956, it may be determined when the shipment is a cross dockshipment. At block 958, cross dock processing may include consolidatingshipments into waybills. At block 960, required documentation may becreated, such as to ship the materials through customs. At block 962, ifthe shipment is not a cross dock shipment, but a direct shipment, it maybe determined whether to consolidate via a waybill. At block 964, ifconsolidation is being accommodated with a waybill, the waybill may becreated. At block 966, whether or not a waybill is created, a Pro-form aInvoice may be manually created for the direct shipment. Using thedelivery document number, the pro-form a invoice can be output andincluded with the shipment to facilitate custom processing.Logistics=>Sales/distribution=>Billing=>Create (VF01).

At blocks 968 and 970, regarding the semiconductor industry, a MasterCommercial Invoice and Master Content List may be created for a CustomsTransaction. The user may enter the required customs and shippinginformation. If the company is using manifest shipments, the waybillnumbers may be entered here and consolidated into one manifest shipment.Either way, all materials included in the shipment may be included onthe Master Commercial Invoice with inter-company pricing. In addition,the Master Content List may be output. These documents may accompany theshipment and may be output and sent to the Service Provider as well.

At block 972, the billing block, transit to cross dock, may be placed ondelivery. At block 974, the goods may be posted to issue. At block 980,if a single delivery is to be shipped via a cross-dock, a custom billingtype can be created by copying the F8 and using inter-company invoice IVpricing settings. This document can then be created at this point usingVF01. The materials are now ready to be shipped. At block 978, customsmay be processed by the service provider. At block 980, the billingblock, receipt at cross dock, may be placed on delivery. At block 982,the shipment may be broken down at the service provider location. Atblock 984, the shipment may be made to the customer. At block 986, thebilling block may be removed on delivery. At block 988, the tradeinvoice (F2) may be sent.

A Goods Issue may be executed for a single delivery (VL02N). The postgoods issue transaction may be performed after a delivery is completelyprepared for shipping. This transaction updates the inventory andinitializes the required financial postings. This transaction or anabove script may be used. Logistics=>Sales & Distribution=>Shipping andTransportation=>Outbound Delivery=>Change (VL02N). In the semiconductorindustry, manifest shipments may be used in order to combine multipledeliveries for shipment for one carrier. This solution may not covermanifest shipments as they are not necessary for shipping purposes.However, some semiconductor companies use manifest shipments to save onfreight costs.

Inter-company Billing may be used for Cross Dock shipment (VFO1). TheInter-company Invoice, such as at block 976, may be created initiallyfor Cross-Dock shipments. Subsequently the Trade Invoice, at block 988,may be used when the Cross-Dock is finally released for shipment to thecustomer on the due date. The timing between creations of Inter-companyand Trade Invoices may depend on Shipping/Customer Receiving dates.Logistics=>Sales/distribution=>Billing=>Create (VF01).

A billing block to the Trade Invoice may be temporarily created whenthis Trade Invoice is issued at an A/T or Service Provider processing aCross-Dock Sales Order, with SAP's Direct-Ship functionality. This maybe conditioned that the goods, remain in Company X premises and areowned by Company X. The Billing Block code is TR for Transit toCross-Dock. To place the billing block on the Delivery, the user mayselect Goto−Header−Financial Processing.Logistics=>Sales/distribution=>Shipping=>Change (VL02).

When receiving at Cross Dock Facility, regarding a Service Provider'sactions, a billing block to the Trade Invoice may be temporarily createdwhen the Trade Invoice is issued at an A/T. Otherwise, the ServiceProvider may process a Cross-Dock Sales Order, with SAP's Direct-Shipfunctionality. This may conditioned that the goods, remain in Company Xpremises and are owned by Company X. The code may be changed to RV tosignify receipt at the x-dock and to continue to block trade invoicecreation. To place the billing block on the Delivery, the user mayselect Goto−Header−Financial Processing.Logistics=>Sales/distribution=>Shipping=>Change (VL02).

When shipping from Cross Dock to Customer, such as for the ServiceProvider's actions, the Billing Block (VL02) is removed, such as atblock 986. This script may be used by user when a delivery note with aBilling block code is obtained. Removing all blocks may enable thecreation of the Trade Invoice, such as at block 988. To remove thebilling block on the Delivery, the user may select Goto−Header−FinancialProcessing. Logistics=>Sales/distribution=>Shipping=>Delivery=>Change(VL02).

Regarding direct shipping, at block 990 good issue may be posted. Atblock 992, trade invoices may be created and at block 994 inter-companyinvoice may be created. At block 996, custom processing may beaccomplished. At block 998, the shipment may be made to the customer.

For cross dock and/or direct ship, the two invoices are created, e.g.,the trade invoice (F2) and the inter-company invoice (IV) may bedisplayed and verified. (VA03). The F2 or master commercial invoice inFIG. 6 may handle external billing to the customer, and invoice (IV) mayhandle internal costs, such as associated with transferring the materialfrom one company code or plant to another. The script may demonstratethat in a direct ship or cross-dock, a trade and an inter-companyinvoice are created. It may also show that the inter-company billing isbetween two internal company codes.Logistic=>Sales/distribution=>Sales=>Order=>Display (VA03).

Credit Checking

FIG. 10 is a flowchart illustrating a process for credit checking.Credit checking may involve various functions. At block 1002, a file fora new customer may be created. Credit Limit may be defaulted to ‘zero’and that the Risk-Category may be defaulted to ‘NEW’ for a newly createdcustomer. At block 1004, the new customer may be assigned to an accountgroup. At block 1006, a new order may be created.

As described later in more detail, the process of the system may confirmthat an order create is not allowed when Credit limit is ‘zero’ and Riskcategory is ‘NEW’. The process may demonstrate how to assign Creditlimit and Risk category. The process may confirm that without aNext-Review-Date assigned, both order create and delivery create isdisallowed. The process may confirm that once a Next-Review-Date ispassed, both order create and delivery create is disallowed. The processmay confirm that with Risk-Category of UNL (unlimited amount) of ordersand deliveries may be created if the next-review-date is assigned. Theprocess may confirm that with Risk-category other than UNL or CH (credithold), order can be created regardless of the total amount of exposure(open invoice+in process delivery+backlog), assuming next-review-date isassigned. The process may confirm that when the credit limit isexceeded, delivery notes can be created (with a warning message) butthey may be blocked for further processing (Picking/packing) until theyare unblocked, assuming next-review-date is assigned. Similarly, whenthe process fails aging invoice control criteria, delivery notes may becreated, such as with warning message, but the process may be blockedfor further processing, assuming next-review-date is assigned.

Described herein are credit checks and the credit information that maybe established for each company code. The configuration for individualcustomers is also covered. The different types of credit checksavailable and outline the industry best practice are discussed. In orderprocessing, the credit status may be used to block the followingfunctions: Creating material reservations; Creating purchaserequisitions; Creating production orders/planned orders; Creatingdelivery due indices; Printing order confirmations; and Creatingdeliveries. In Shipping, the credit status can be used to block picking,packing, posting goods issue, and printing delivery notes. In standardSAP R/3 there may be nine different types of credit checks that can beperformed. A user may define any one of the checks for variouscombinations of credit control area, risk category, and document creditgroup.

For a static control check, a customer's credit exposure may not exceedthe established credit limit. The credit exposure may be the totalcombined value of the following documents: Open orders; Open deliveries;Open billing documents; and Open items, such as accounts receivable. Theopen order value may be the value of the order items which have not yetbeen delivered. The open delivery value may be the value of the deliveryitems which have not yet been invoiced. The open invoice value may bethe value of the billing document items which have not yet beenforwarded to accounting. The open items may represent documents thathave been forwarded to accounting but not yet settled by the customer.

At block 1008, the process determines whether the delivery date iswithin a horizon. A credit horizon may be used in SAP to specify theduration of time that may be taken into account when checking acompany's credit. The system may be set up to only review certain typesof documents and the date that the document impacts. At block 1010, ifthe delivery date is within the horizon, the process performs a creditcheck. For a dynamic credit limit check such as with Credit Horizon, oranother credit method, such as another one that may be used with SAP,the customer's credit exposure may be split into a static part, such asopen items, open billing, and delivery values, and a dynamic part, suchas the open order value. The open order value may include allundelivered or only partially delivered orders. The value may becalculated on the shipping date and stored in an information structureaccording to a time period that the user specifies, such as days, weeks,or months. When the user defines the credit check, a user may thenspecify a particular horizon date in the future, for example: 10 days or2 months, depending on the periods the user specifies. For the purposesof evaluating credit, the user may want the system to ignore all openorders that are due for delivery after the horizon date. The sum of thestatic and dynamic parts of the check may not exceed the credit limit.

Regarding a maximum document value, the sales order or delivery valuemay not exceed a specific value which may be defined in the creditcheck. The value may be stored in the currency of the credit controlarea. This check may be useful if the credit limit has not yet beendefined for a new customer. The check may be initiated by a riskcategory which may be defined specifically for new customers.

The credit check may be triggered by changes made in the document tovalues in any of the credit-sensitive fields. According to the user'scustom settings, the system may run a check credit between changes ordifferences in the sales order data against the default values in thecustomer master record. Examples of such fields may be terms of paymentand fixed value dates. The process may use the date of the next creditreview as a trigger for an automatic credit check. If the user processesa sales order after a customer's next review date has expired, thesystem may automatically carry out a credit check. The relation betweenopen items which are more than a certain number of days overdue and thecustomer balance may not be allowed to exceed a certain percentage. Theoldest open item may not be more than a specified number of daysoverdue. The customer's dunning level may only reach a specified maximumvalue. To carry out checks other than the standard checks, a user maydefine checks in the appropriate user exits in Customizing for Sales.The Credit Limit may be managed on different levels, such as the CentralOffice (COF) level, the Credit control Area (CCA) level, or theindividual Payer level:

In SAP, credit may be controlled at the credit controlling account(CCA), which may default to the Payer level. When a new Sold-to customeris created, the Payer and credit controlling account, such as on thecredit master record, numbers may be defaulted to the Sold-to number.This type of setup may support the options above. In this scenario, anindividual credit limit may be established and credit checking may beperformed at the individual payer/CCA level.

Scenario 1. SP1------------PY1(CCA1=PY1)

-   -   SP2------------PY2 (CCA2=PY2)    -   SP3------------PY3 (CCA3=PY3)

In this scenario, invoices may be billed and customer statements may besent to the individual payers.

In the semiconductor industry, in addition to SAP's default creditmanagement system, the following two scenarios may be configured to meetthe needs. If multiple Sold-to's share the same Payer, the credit limitmay be managed collectively. The user may therefore assign each of theSold-to's to the same Player. The payer number may relate to one, andonly one, credit control area in the credit master record. When an orderis placed for any sold-to which is tied to this collective payer, thecredit may be managed at that payer/CCA level.

Scenario 2. SP1------------PY1 (CCA1=PY1)

-   -   SP2------------PY1 (CCA1=PY1)    -   SP3------------PY1 (CCA1=PY1)

In this scenario, invoices may be billed and customer statements may besent to the collective payer. A difference from the first scenario isthat the first scenario may take into account only one groups' financialtransactions. In the second scenario, multiple groups may contribute tothe data collected when the credit check is performed.

It may also possible to manage the credit limit at the COF (CentralOffice) level. There may be one COF number per multi-national customerper region. For example, all of the Customer Y Sold-to numbers in theUSA may link to one common COF number while all of the Customer Ysold-to number in Asia may link to a different COF number. This rule mayapply for all other regions as well. The four COF numbers may furtherconsolidate to a World-Wide Consol number for reporting purposes.

The following scenario is an example, where the credit limit is managedat the Customer Y USA COF level, as well as at the individual payer/CCAlevel. Although there may be multiple Payers, this can be achieved byassigning a COF number to all of the Payer/CCAs that are to be creditcontrolled by this COF on the credit master records. The credit limitmay be set at both the individual payer/CCA levels as well as at the COFlevel. The credit checking may also performed at both levels.

Scenario 3. SP1------------PY1 (CCA1=PY1)--\

-   -   SP2------------PY2 (CCA2=PY2)---->COF    -   SP3------------PY3 (CCA3=PY3)--/

In this scenario, invoices may be billed and customer statements may besent to the individual payers.

Finally, in some cases, it may be necessary to control the credit limitcollectively yet continue to bill the payers individually. This may beachieved with the following setup. The individual sold-tos may be tiedto the individual payers, therefore allowing for the individual billingsand customer statements. However, each of the payers may be associatedwith the same CCA, therefore, collectively controlling the creditchecking.

Scenario 4. SP1------------PY1 (CCA1=PY1)

-   -   SP2------------PY2 (CCA1=PY1)    -   SP3------------PY3 (CCA1=PY1)        -   credit checked at CCA1

In this scenario, invoices may be billed and customer statements may besent to the individual payers.

Base SAP may manage credit limit at one level, either at Payer/CCALevel, which may be one Sold-to or multiple Sold-to numbers, or at thecollective level as in scenario 4. Without custom code, the SAP may nothave the capability to manage credit limit at individual level as wellas the COF level. The user, typically the credit manager, may assign thePayer with any Credit Controlling Account, on the credit master record,even if the CCA has no relation to the sold-to. In another words, SAPmay not validate the CCA to prevent human error.

The following credit control settings may be recommended for thesemiconductor industry. Credit checks may be based on the followingconfiguration settings: Credit Horizon, Date of Next Review, OverdueOpen Items, Credit Limit, and Risk-Category. The credit limit may bemanaged at the Central Office and payer levels, as per Scenario 3. SinceFinancial Accounting and Sales Processing are centralized, the CCA maybe the same as the Sales Organization, meaning there may be one CCA percountry. This may be true for all geographies. There may be exceptions,however, such as Asia. Certain Asian countries such as Japan may requireseparate CCAs due to unique country regulations and requirements.

A dynamic, horizon based credit check may be used. The credit check maybe invoked at delivery note generation. When the credit check occurs,the credit limit may be compared against all the orders within thehorizon. The credit check date may be based off of the EPSD (EarlyPossible Ship Date). If there is no credit problem, a delivery note maybe created automatically when the delivery date is reached. If there isa credit issue, the system may automatically block delivery create forall orders in the horizon and the credit manager may have to releaseorders manually. The horizon may be configured for each risk category.Since it is under configuration and is controlled by security level,users cannot view or change the horizon in the credit master file.

At block 1012. if an order fails the credit check at order create,delivery note create, or during the run of the batch job, the order maybe blocked and may appear on an on-line report displayed through SAPtransaction code VKM1. At block 1014, when appropriate, a user, such asa credit manager, may release each delivery that failed the credit checkindividually. The release concept in SAP may be that of a “horizon”release. A release may approve credit for all items within the horizon.At blocks 1016, 1018, and 1020, every order and delivery within thehorizon may be released and may not be subject to future credit checks.Any items which were outside of the horizon may be checked once theymove into the horizon, and at that point the order may be blocked againaccording to the credit status at that point in time.

At block 1022, if the sales documents are released manually, manualsales documents may be prepared. At block 1024, a deliver note may becreated. At block 1026, a transfer order may be confirmed. At block1028, the posted goods may be issued. At block 1030, the billing mayoccur.

A Risk-Category of UNL (“Unlimited”) may be assigned by the user to meanthat unlimited orders and deliveries can be created, regardless of thecredit limit status (credit limit−[open invoice+delivery+open order]) orthe number of aging invoices. Using this risk-category may be similar toexcluding a customer from credit checks. For customers who have creditproblems, a risk category of CH (credit hold) may be used.

This risk category may trigger a credit check at both order create anddelivery create events. At blocks 1032 and 1034, if the delivery date isnot within the horizon, or the delivery date is within the horizon andthe credit check passed, the order may be created. At block 1036, if theorder was not created within the horizon, or if the order was createdwithin the horizon but blocked, manufacturing may be updated and/orunits for the order may be frozen. Thereafter, such as at block 1038,the process may again determine if the delivery date is within thehorizon. At 1040, if the delivery date is not yet within the horizon,the process may continue to check for the next horizon. At block 1042,when the delivery date is within the horizon, the process may determineif the credit check has passed. Checking the credit may entail checkinga next renew date, checking a credit limit, checking a total amount ofopen items, and other checks, such as checking a risk category.

In addition to the risk-category UNL, other risk-categories may be setup that may be custom tailored to different customers' requirements.These may be configured such that the customer is put on delivery stop,such that orders can still be created, when: a) Overdue Open Itemsexceed a certain % (the percentage is configurable); b) Credit Limit hasbeen exceeded (comparing credit limit with open invoice+delivery+xnumber of days of backlog); and c) Next Review Date has passed. The ‘x’number of days can be utilized in any increment, such as in days, weeksor months. A standard setting may be one day of backlog. SAP may includebacklog into credit calculation in delivery creates, such as at leastone day of backlog, and also the next-review-date. Each user, such as aregion credit manager, may decide which risk-categories are needed andthe percentage of aging invoices to be allowed for each of them.

The system may be configured such that next-review-date is mandatory indelivery create. The process of this system may help the credit managertrack the customer's credit. The system also allows users to input sometext to serve as a reminder as to the purpose of the coming creditreview. The Next-Review-Date may be configured for each individualcustomer in the system, however, if there are users who do not find thefunction useful, they can assign a next-review-date very far in thefuture, such as fifteen years in the future. A rationale for allowingdelivery note creation but blocking the pick/pack process in the case ofinsufficient credit limit or large amount of aging invoices may be foroperational efficiency. The credit manager may then be able to browseall of the delivery notes blocked and work on each of them. As soon asthe credit problem is fixed, he/she can then unblock the order.

FIG. 11 is a flowchart illustrating a two-level credit check for a payerand central office. At block 1100, customers may be arranged byhierarchy. The hierarchy may include different levels of central officecustomers C1, C2, C3, worldwide (WW) customers and sold to customers. Atblock 1102, a credit hierarchy may be established for the customers. Forexample, the credit limit set for COF (C1) may be affected by payers 1to N and/or an established credit limit for the payers, such as payer(PY1) which is a payer for a sold-to customer of the COF (C1) customer.At block 1104, an order is entered. At block 1106, it is determinedwhether a credit limit of the payer is exceeded. Factors such as riskcategory, next review date and/or credit limit may be considered. Atblock 1108, if the credit limit is exceeded, the order may be blockedand an order number created. At block 1110, blocked orders may bemanually released. At block 1112, if the order is released, a deliverynot may be created. At block 1114, billing may occur after the deliverynote is created. At block 1116, if the credit limit of the payer was notexceeded, the credit limit of the central office customer, such as COF(C1) which sold to the payer, may be checked. At block 1118, if thecredit limit of the central office customer is not exceeded, the ordermay be created, the delivery note may be created (block 1112) and thebilling may occur (block 1114). Otherwise, at block 1120, if the creditlimit of the central office is exceeded, the order may be blocked.Blocked orders may be manually released (block 1110).

FIG. 12 is a flowchart illustrating an exemplary credit check for a newcustomer. At block 1200, a sold-to credit account may be created for thenew customer. At block 1202, a credit limit and risk category may bedisplayed to the user. At block 1204, a created order may be verified.At block 1206, a risk category, such as unlimited (UNL), may be assignedto the customer. At block 1208, a newly created order may be verified.At block 1210, a delivery date may be verified. At block 1212, a nextcredit review date may be assigned. At block 1214, any delivery thatoccurred may be verified. At block 1216, a next review date may beassigned. At block 1218, a verify order may be created. At block 1220, averify deliver may be created, such as after a lag time in processing.At block 1222, the risk category, credit limit and next review date maybe set. The risk category may be set, such as to perform a dynamic checkby using SAP standard code of ‘A’. At block 1224, a verify order may becreated with an amount exceeding the credit limit. At block 1226, averify delivery may be created with an amount exceeding the creditlimit. At block 1228, picking may be verified for different steps in theprocess where credit checking may be taking place, such as depending ona setting chosen for the customer.

The following is a general flow of what may follow from using the systemand process described above. New customers may be handled by beingdefaulted to credit values that do not permit order entry. After Creditlimit, Risk category are setup, an order can be created but NOTdelivered. Delivery may be created after Credit Limit, Risk-category and‘Next-Review-Date’ are set up. The user may create a new sold-to andassign the same sold-to number as the payer, bill-to & ship-to. Asold-to file may be created with default ship-to/payer/bill-to. Thecustomer may be tied to a Credit Control Area and Central Office, ifnecessary. A customer's credit account may be displayed. The user mayview the fields that determine the customer's credit standing. The usercan view the customer's Credit Limit, Receivables, Credit Block flag,Risk Category, Credit Rep. Group, Last Review Date and Next Review Date.For a new customer, the Credit limit may be zero and the risk categorymay be NEW.

When creating a standard order, on an overview single-line entry screen,after clicking the save button, the order may not be created. The usermay receive an error saying E: Dynamic credit limit exceeded. The usermay be able to update the credit limit, risk category, and next reviewdate at the same time or execute the scripts individually. Setting thecustomer's credit limit may be used to set both the individual payer'scredit limit as well as the central office credit limit. The statusfield may be marked after entering relevant data and pressing enter. Thecustomer's credit limit may be entered in the <Credit limit>field. Thismay set the upper limit for total receivable and the data may be saved.

In the same screen as above, the customer's risk category may be enteredin the relevant category, such as <Risk category>field, and the data maybe saved. A date of internal review may be set by credit manager. Thecredit manager may be alerted on the date set in this field to perform acredit check for the customer. The field may be reset every time thereview date passes. If the users do not wish to set a date for thecredit manager to review the customer's credit, a user can set the datevery far in the future (e.g. Sep. 9, 9999). The order may be created atthis time. A date of internal review may be set by the credit manager.This time the next review date back may be set to blank. The next reviewdate may be removed. To create a delivery note, on the quantities screenafter clicking the save button, the delivery may not be created. Theuser may receive an error saying E: Credit check: customer review datehas passed.

The date of internal review may be set by credit manager. A deliverynote may be created. The same sales order may be used for the lastdelivery create, in the prior steps. This time the delivery may becreated. The date of internal review may be set by credit manager. Thistime the user sets the next review date to a date in the past, as anexample that may be set in the system to show functionality of an errorreceived when the date passes. Under normal operating conditions, thismay not normally be done. After the date passes, the user may receive awarning saying that the next check is in the past. The user may continueby clicking the ENTER button. To create an order, such as with a manualinput, with the create standard order of the process, an error may occuron an overview single-line entry screen after clicking the Save button.A user may receive an error saying Credit: customer review date haspassed. In this case, no updating may be possible.

An internal review by credit manager may be set. This time around, thenext review date may be set to a date in the future, therefore an updatemay be successful. The order may be created this time. The date ofinternal review may be set by credit manager. The time for the nextreview date may be set to a date in the past. The user may receive awarning saying that the next check is in the past. The user may continueby clicking the ENTER button.

On the Delivery Create, for the quantities screen after clicking thesave button, the delivery may not be created. The user may receive anerror saying E: Credit check: customer review date has passed. The usermay set customer's credit limit to low. The user may set customer's riskcategory to low risk. The user may set date of internal review by creditmanager and set the next review date to a date in the future. The threeprevious steps may all be executed on the same screen at the same time,or separately on separate screens, depending on an implementation.

The user may input a quantity so that the value of the order is greaterthan the credit limit. Order may be created without a warning or error.On the quantities screen after clicking the save button, the deliverymay be created but the user may receive a warning first saying dynamiccredit limit is exceeded. The delivery credit status may also beblocked. The user may enter the pick quantity on the deliver change.This procedure may assume that the storage location for the shippingplant is non warehouse management system (WMS) controlled. The processmay be modified slightly if WMS has been implemented. The pickingquantities may be updated on the Delivery Note without referring to anypick location. The Delivery status may be changed to “C” which mayindicate that the delivery is completely processed.

The user may pick a delivery, without WMS, on the change deliveryscreen, instead of clicking the picking button, by click the packingbutton. The packing items screen may display an error stating that thedelivery status only allows a display mode. A goods issue may beexecuted for a single delivery. On the delivery change screen, afterclicking the post goods issue button, the user may receive an error onthe display log screen stating that goods issue from delivery are notpossible due to credit block-dynamic credit limit exceeded. Thisprevents the post goods issue from successfully processing. The user mayrelease the order from credit block. Individual orders may be releasedwithout changing the customer's credit profile by using SAP transactioncode VKM1. The user may select the order to be released, and click thebutton with an icon, such as a green flag. The credit block may beremoved from the order such that the order is ready for furtherprocessing.

Expedite Orders

A basic functionality may be demonstrated for backlog management afterthe receipt of an expedite delivery order from the customer. The processmay take place when a customer needs to receive an order sooner thanexpected, or make another change to the order. Expediting the order mayimprove the chances that a delivery is created for the order, which mayin turn speed up shipping. The process may include finding and listing areferenced backlog item, determining the status of the item, anddetermining the required course of action for satisfying the customer'srequirements. This process may include sources for finding current orderinformation to assist the user in evaluating what actions may berequired.

The process may be used by various users, such as credit managers, fieldsales, sales managers, customer service, distribution centers, productmarketing, and product planning. The process may explain how to locate acustomer order by sold-to, purchase order, material, or order number.Additionally, the process may show how to determine theproduction/shipping status of the backlog item. Steps to change arequested delivery date, delivery priority, delivering plant, partialshipment, ship-to location may be included by the process. The processmay automatically create the delivery for an order/item, if required.

Depending on the business process, not all expediting options mayincrease the chance of a delivery document being created. For example,not all companies choose to utilize the delivery priority as part ofbackorder processing. In the semi-conductor industry, foundry companiesmay focus more on manufacturing than research and development. So,sophisticated ERP manufacturing and planning linkages may need to meetthe needs of their time dependent businesses. Since the majority oftheir business may be based on make-to-order scenarios, they may needadditional tools to meet customer demands while recovering anyadditional costs necessary to reduce manufacturing lead times. Customcode may be recommended to meet the requirements of hot runs and superhot runs.

Customers may be continually requesting material to be delivered inunder its published manufactured lead times. In these situationsfoundries may require the creation of an expedited order. Based on adelivery time field, a designation of hot run or super hot run may beselected at the item level. When each is selected the manufacturing leadtime may be reduced, allowing the requested delivery date to be madesooner. The field change may also carry out new pricing which mayincrease the uplift charges associated to the line item. The decrease inmanufacturing lead time as well as the increase in material price may bedefined when the material is entered into the system or is individuallynegotiated with the customer.

FIG. 13 is a flowchart illustrating an expedited request process. Atblock 1300, a request to expedite an order may be received from acustomer. The process may allow the user to determine the current statusof a backlog items and attempt to make order revisions or takeappropriate actions to achieve the customer's required delivery date.The process may address several of the more common reasons for acustomer to expedite a shipment. In addition to the described process,other actions may be used to address other conditions such as exceedingcredit limits, credit blocks, customer master blocks, customers onboycott lists, export license checks, and other similar reasons that mayprevent shipment to the customer. There also may be other orderconditions that impact order expediting, such as with regard tobackorder described below.

At block 1302, the process determines if the order was backordered,e.g., the order is not in stock. To determine a current order status,sales order documents may be listed by a sold-to, ship-to, material, orPurchase Order number. Using the available information, a transactionmay be used to search for the appropriate order. After finding theorder, a details button, such as from a tool bar, may be used to reviewthe displayed information such as organizational data, partnerfunctions, or other selection criteria. The user may double click on theorder to access the order is display mode. An order may be displayed toview materials, quantity, prices, business data, and partner data of anorder. Once the sales order number is input, the sales order informationmay be displayed. If the order is delayed, the reason may beinvestigated during this transaction. A useful screen may be at the itemlevel. A schedule lines tab may be used where the result of the ATPcheck is displayed and can be researched, such as by using a ‘check itemavailability’ button.

The plant stock availability may be checked to determine materialavailability for meeting customer requirements. Inputting the materialnumber may provide the plant and storage location of the material thatis available. This process may be performed to determine whether or nota specific plant has the necessary stock to fulfill a customer order.Transactions may also be used to review Available to Promise (ATP)inventory. The user may determine what material is in transit to thewarehouse. Using the internal part number, a list of the purchase orderswith that part number may be displayed. A search may be performed for aspecific plant for all plants if this field is blank.

At block 1304, is the item is not backordered, the user may manuallycreate a delivery entry. Creating early delivery may cause an earlyshipment/pull ahead for a delivery that was created for a sales orderscheduled in the future. If there is a business need to ship aheadcertain sales order/line items previously created, this function may beused. At the time the delivery is created, a delivery note may beissued. At block 1306, the user may then move up the delivery date, suchas based on the customer's request. The user may input the selectiondate, the shipping point, and the sales order. A delivery number may beprovided. This action may require business approval. At block 1308, ifnecessary, the user may change the ship-to location.

At block 1310, if the order is backordered, the user may perform anotherATP check. In addition, other action may be performed to try to supportthe customer requirements. At block 1312, the delivery priority may bechanged to a higher delivery priority to allow a larger pool ofinventory to be considered. At block 1314, an alternative plant deliverylocation may be selected, which may help to expedite the order.Reviewing stock levels using SAP transaction code MMBE and C009 caninform the user of possible alternate plants for the order. Using thedrop down menu from inside the plant field may display the maintainedplants for a line item. Changing the plant may re-trigger ATP. At block1316, the material may be changed to try to help expedite the order suchin the case where an alternate material has been identified aftertalking with the customer.

At block 1318, the user may change the quantity by authorizing a partialshipment for an order item, such as if permitted by the customer. Afield may be used for the user to indicate whether or not a partialshipment is acceptable for a line item. The user may ship an availablequantity as a partial delivery/partial shipment. Picking may involvepreparing goods of the correct quality in the correct quantity forshipping on schedule to a customer. Picking may be carried outseparately for each delivery. This function may allow part of a deliveryto be sent to the customer if the full delivery is not available. Thesecond pick may occur once the materials are available to satisfy thefull order quantity. At block 1320, to accomplish the partial delivery,a requirement for a complete delivery may be removed, if applicable.

A shipping carrier on an order may be changed. A carrier change may bemade for material that is to be delivered at some future date, on aspecific item shipment only, without altering any of a customer'sstandard shipping instructions. This may be adjusted using theforwarding agent/freight forwarder partner function. The user may changethe ship-to partner at header or item level. The ship-to partner may bechanged at the customer's request. This may be done for individual itemsor at the header level so that it may be applicable to the entire order.The customer requested delivery date may be changed if the customerneeds it to be modified. This may be adjusted using the ‘First date’field if the change is for only a specific line item. The user may usethe ‘Fast change of’ field if all line items are changing. The headerlevel Request Delivery Date (RDD) may not copy down to the line items.Changing the RDD may automatically re-trigger ATP. For an urgent shiprequest, the shipping condition in an order may be changed. The schedulemay be recalculated according to the new shipping condition. Inaddition, a delivery plant location may be changed for an item within anopen order for multiple items. The plant, shipping point, route, andstorage location may also be changed.

Partner Determination

Partner determination features, such as for an SAP system, arediscussed. Partner determination may identify and assign differentpartner functions to document types and account groups. When a documentor customer is created, the procedures which have been assigned mayidentify the partner functions that may be mandatory and optional foreach of the areas. By using Partner Determination, a user may definewhat business partners, such as Ship-to, Bill-to, Field Sales etc., maybe included in each sales document or customer record, such as SalesOrder, Delivery etc. Also, a user may define what partners are connectedto the business partner itself. What partners are entered on the partnerview when a user creates a new business partner in the customer mastermay be determined by partner function.

FIG. 14 is a block diagram showing a process for partner determination.Partner determination may include the following steps. First, at block1400, a partner function field may be established to distinguish betweenthe functions of partners. A user may define partner type, e.g.customers, vendors, customer's employees or a user's employees,higher-level function to define dependencies between partner functions,and whether or not the customer is unique in the customer master, etc.The customer master is a section within SAP that may hold all salesrelated persons that the company does business with. Within the customermaster business partner functions may be assigned that classify the datathat is entered by identifying it, such as ship to location, bill to,sales representative, etc. A user may also assign customer accountgroups to the partner function. In this way, a user may limit allowablecustomer account groups for the partner function.

Second, at block 1410, a user may group partner functions which areallowed for a partner object in a partner determination procedure. Auser may allocate the grouped partner functions to the keys of therespective partner object. A user may also define a partner functionattribute in the partner determination procedure, such as ‘mandatorypartner’, ‘changeable partner’ and etc. Third, a user may assign partnerdetermination procedure to the key of the respective partner objects.Available partner objects and their keys may include the following:

TABLE 1 Partner Object Key Customer Account group Sales doc. headerSales document type Sales doc. item Item category - sales documentDelivery header Delivery type Shipment header Shipment type Billing doc.header Billing document type Billing doc. item Billing document typeContact Contact type

At block 1420, allowable customer account groups may be assigned topartner functions. A partner procedure may be assigned to an accountgroup. In this way, a new partner function and procedures may be definedfor the customer account group which a user creates. Also, businesspartners may be created in the customer master.

FIG. 15 is a block diagram of an exemplary sales document header. Thecustomer account group 1420 may be assigned to the partner function1400. At block 1500, the partner procedure 1410 may be assigned to asales document type, such as inquiry, quotation, returns, standardorders, etc.

FIG. 16 is a flowchart illustrating partner determination for a customermaster. The following steps may represent the general system flow of thepartner determination process. At block 1600, a customer account groupmay be created. The account group may be a classifying feature withincustomer master records which is assigned at the beginning of thepartner determination procedure. The account group may determine whichnumber range the customer account number should be, whether the numberis assigned internally or externally, and which fields may be necessary,or possible, to be filled out in the master record. A user may alsodefine the text determination procedure and a type of pricing which isused with that master record.

A number range may be defined for a customer account group. Whencreating a customer master record, a unique number which identifies themaster record may be assigned. The number may come from the number rangethat is provided for the account group. There may be two types of numberassignments, internal and external assigned numbers. Internally assignednumbers may be used, for example, such that SAP can manage the sequence.Number ranges may be set up with two separate ten digit numbers that donot overlap other number ranges. A different number range may be usedfor each of a user's different customer types so that users can identifythe type by the range that is used. In the semiconductor industry, threeaccount groups may be used for customer creation. The standard accountgroup may be used for domestic, international customers, distributors,and end customers. The account group CPD may be used for one timecustomers. A special inter-company account group (ZINT) may be set upfor inter-company customers.

At block 1602, partner functions may be created. Partner functions maybe objects that specify the relationship, for example, the function orresponsibility, which the holder of the role has to the appropriationrequest. The standard SAP partner functions, such as sold-to party,bill-to party, or payer, for example, may be supplemented with furtheruser-defined partner functions. In the semiconductor industry,additional partner functions may be used in other to provide furtherinformation. Other companies may add the following partner functions tothe sold-to partner determination procedure: Field Sales Representative(FR), Field Sales Assistant (FA), and Carrier (Freight Forwarder) (CR).These partner functions may be listed as optional on the Sold-to record.These partner functions may be linked to the Sales Document Header, theCustomer, and the Billing document, as necessary.

The ability to track distributor end customer sales may be customizedand a partner function of (EC) may be used. The distributors may need toinclude the end customer's information in pre-established fields so thatwhen information is sent the system can make the association or create anew EC customer record. The customer record may also be connected to theappropriate customer hierarchy. An end customer sales office may then beattached to the EC partner function. The last partner function may bethe function used during Cross Dock (CD). The partner function may beadded to a sales order when a material is going to be sourced from aplant outside the country and the material does not return to theoriginating sales order country before being shipped to the endcustomer. The partner function may be connected to an outputdetermination so that additional documentation may accompany thematerials when they are sent to the customs location.

The Cross Dock partner function may allow for a vendor to be set up toact as the cross docking agent. The vendor may be no more than theaddress of the customs location and may not have the full functionalityof a full vendor. Therefore, a separate vendor account group may becreated in order to accommodate this. The customized vendor group “ZRCD”may be linked to the customized partner procedure for cross docking “CD”as well as the customized partner function for the cross docking address“CD”. The partner function “CD —Cross Dock Address” may be linked to theSales Document Item, Delivery, and Billing document header.

At block 1604, the user may create a partner determination procedure.Partner determination procedures may summarize all partner functionsthat are allowed for a partner object in a partner determinationprocedure. A user may then assign a partner determination procedure to akey. The partner functions contained in the determination procedure maythen be relevant in the record type to which they have been assigned.

At block 1606, the user may assign partner determination procedure tothe customer account group. By assigning the partner determinationprocedure to the customer account group, the associated partnerfunctions and mandatory field entries may be displayed when the customeris created. All customers may need to have an account type selected whenthey are created to define required fields and assign the appropriategeneral ledger accounts. At block 1608, a partner may be created using adefined account group.

FIG. 17 is a flowchart illustrating partner determination for a salesdocument header. Partner functions may be created. The partner functionsmay be objects that specify the relationship, for example, the functionor responsibility, which the holder of the role has to the appropriationrequest. Standard SAP partner functions, such as sold-to party, bill-toparty, or payer, for example, may be supplemented with furtheruser-defined partner functions. A partner determination procedure may becreated. The partner determination procedure may summarize all partnerfunctions that are allowed for a partner object in a partnerdetermination procedure. A user may assign a partner determinationprocedure to a key. The partner functions contained in the determinationprocedure are then relevant in the record type to which they have beenassigned. The standard TA (standard order) procedure may typically beused for sales orders.

A partner determination procedure may be assigned to the Sales OrderHeader. At block 1700, the user may view a procedure assigned to a salesdocument. At block 1702, the procedure definition may be viewed by theuser. At block 1704, the user may check the partners on the sales order.By assigning the partner determination procedure to the sales orderdocument type the associated partner functions and mandatory fieldentries may displayed when the customer is created. The procedure maydefine the mandatory partner functions for each document as well asallowing the inclusion of optional partner functions such as for a salesrepresentative.

Inter-Company Pricing

This demonstrates a billing procedure that may be used for inter-companyorders of semi-finished and finished goods. A general process ofcreating an invoice is discussed as well as two processes that may beused for inter-company pricing. The procedure outlined may be usedmainly for orders that involve two or more company codes. In thesemiconductor industry, the calculation process that is used may bedetermined by the unique combination of the Seller, the Buyer and thegood being sold, and may be either the “Cost-Plus” Method or the“Resale-Minus” Method. The process may be used by business planning andfinancial control users.

Inter-company pricing in SAP may be customizable. The pricing proceduresused may be configured to meet very detailed requirements of differentcountries and organizations. The general process used for inter-companybilling, regardless of the customization used, may be as follows. Thedelivering plant may process the delivery to create an inter-companybilling document (such as type IV) for the selling company. The companycode may post the invoice entry for the billing document. The billingdocument may be automatically billed to the internal payer that isassigned to the sales organization. The inter-company charges thatappear in the inter-company billing document may represent the actualamount that the delivering plant is charging the sales organization. Instandard SAP, this amount is derived from one of two default conditiontypes: P101 Inter-company (fixed amount per material unit) or P102Inter-company (percentage of the net invoice amount). These conditiontypes specify that the price charged by the delivering plant to thesales organization is shown as a statistical value in the sales orderand an effective charge in the internal invoice. These condition typesmay function in the same manner as normal pricing conditions and may bemaintained in the Sales and Distribution (SD) pricing master datascreen.

In the semiconductor industry, pricing conditions may be highlycustomizable. This process may demonstrate a pricing procedure that isrecommended for the semiconductor industry that is referred to asZINTER. ZINTER may include two methods of pricing: Resale-minus pricingand cost-plus pricing. The entities concerned are mainly WaferFabrication plants, A/T plants, and DC/Sales Organizations.

A ZINTER pricing procedure follows. An inter-company sales order may bepriced according to two methods: Cost-Plus or Resale-Minus Pricing. TheCost-Plus method may use the base price of the good, and marks it up bythe amount specified in the profit factor condition type. This may beused mainly for semi-finished goods. The Resale-Minus Pricing method maytake the Resale Price and reduce it by the amount specified in theprofit factor condition type. Entities in Japan may use only resalepricing. Which pricing method is used may depend on the uniquecombination of seller, buyer and good. When a sales order is enteredthat contains two internal customers, the system may automaticallyrecognizes it as an inter-company order, type ZICT. The system may thendetermine which condition type to use, depending on who the buyer andseller are, and what type of good is being transferred. The followingtable explains the different condition types that may be configured.

TABLE 2 Step Condition type Explanation 1 ZICT Inter-company ConditionType, whether it is Cost Plus or Resale Minus 100 ZCWC Cost + Wafer/Chip250 Wafer/Chip Cost Plus Price 300 ZCFG Cost + SFG/FG from A/T 350 A/TSFG/FG Cost Plus Price 400 ZRFA Resale SFG/FG Asia 450 A/T Resale MinusPrice 500 ZPRS Standard from Material Ledger 510 ZMAF Moving AverageFactor 520 Raw Materials at Standard [Equal to ZPRS + (ZPRS * ZCCC)] 600ZCDC Cost + FG from DC 650 DC Cost + 700 ZRFJ Resale SFG/FG Japan 800A/T Resale Minus Price 900 ZBAS Base Price

After the system has determined which condition type to use, it mayselect a special profit factor pricing condition depending again on theunique combination of good, seller and buyer. The profit factorconditions available may include ZAAA, ZBBB, ZCCC, ZDDD and ZEEE. Theseconditions may be maintained in sales and distribution (SD) and fed intothe Pricing Module. In general, the condition type may be drawn from thebuyer/seller level, and the profit factor may be drawn from the materiallevel.

The calculations that may be entered in configuration are demonstratedbelow:

CLAM: Cost Less all Materials

CLC: Cost Less Chip

FERT: Finished Good ready to sell to a Trade Customer

HALB: Unprobed Wafer, CHIP, Non-Turnkey Finished Good

LOAD: Can be loaded from an external source or as a manual load directlyto the SAP pricing Module

MPG: Material Pricing Group

OM: Other Material

OTC: Operational Transfer Cost (Material Ledger Standard from theShipping Plant)

SBE: Strategic business entity (worldwide business)

SOF: State of Finish. A SOF material may be a device that has not beenfully built. For example, it may be a device that has been assembled,but not tested.

Cost+Actual Invoice Price (AIP)

Chip Interface: Wafer AIP/Chips per Wafer/Multiprobe Yield=Yielded ChipAIP.

Chip Interface: Yielded Chip AIP+(Yielded Chip AIP*profit factorZAAA)=Chip Cost+AIP.

A/T Chips: Yielded Chip AIP (derived from wafer fab source)=A/T ChipAIP.

A/T Chips: Yielded Chip AIP+(Yielded Chip AIP*profit factor ZAAA)=A/TChip Cost+AIP.

A/T SFG/FG: (Assy Yield*Test Yield)=A/T Yield Loss.

A/T SFG/FG: (Assy AIP Cost Less All Materials+Test AIP CLAM)=A/T CostLess All Matl AIP.

A/T SFG/FG: (Assy AIP OM+Test AIP OM)=A/T All Other Material AIP.

A/T SFG/FG: Assy AIP CLAM+Test AIP CLAM+Assy AIP OM+Test AIP OM=A/TDevice CLC AIP.

A/T SFG/FG: Wtd Avg Chip AIP/(Assy Yield*Test yield)=Yielded Wtd AvgChip AIP.

A/T SFG/FG: (Wtd Avg Chip AIP)/(Assy Yield*Test Yield)+(Cost Less AllMatl AIP)+(Cost Less All Matl AIP*Assy Test Factor ZATF)+All Other MatlAIP=A/T Device Cost+AIP

Assumptions: SOF devices may be fed the pricing module with theappropriate fields.

Example: Test CLAM and Test OM is fed with 0.00 and Test Yield is 1.00for −ASY devices that have not been tested.

DC FERT: Wtd Avg Chip AIP+Wtd Avg CLC AIP=Wtd Avg Device AIP

DC FERT: (Wtd Avg Device AIP+Finishing Cost Adder+Misc. Adder+DutyAdder)/Yield=FERT Device AIP Std (COB-AIP)

DC FERT: FERT Device AIP Std+(FERT Device AIP Std*Profit FactorZBBB)=FERT Cost+AIP

Resale AIP 1 (Resale Price Factor set at the Buyer Plant Level)

FERT: AUP (Average Unit Price)+(AUP*Price Factor ZBBB (Usuallynegative))=Device Resale AIP 1

Resale AIP 2 (Resale Price Factor set at the Buyer Plant/SellerPlant/MPG (Material Price Group) Level)

FERT AUP (Average Unit Price)+(AUP*Price Factor ZCCC (Usuallynegative))=Device Resale AIP 2

Assumptions: Resale AIP 2 may be used by regions that are required bygovernment authorities to separate resale AIP factors by the Seller andthe WW DC.

In order for the system to process an inter-company sales order, everyinternal customer, for every plant and sales organization, may have oneof the above pricing procedures specified in their customer masterrecord. Each customer may also have the customer pricing procedure(Cust.pric.proc.) field set to ‘I’ (for inter-company). This functionmay be performed in the update customer master transaction (XD02).

The following are three examples to demonstrate logic of the pricingprocedure, for example, in the semiconductor industry:

EXAMPLE A

Company X (Plant 1234)) buys finished goods from various A/Ts that usethe Resale-Minus-Method such as Company X-Malaysia, Taiwan orPhilippines. 1) ZICT may be to “450” for the buying plant. This mayensure that all the inter-company purchases by this buying plant are viathe Resale-Minus Method. Notice that the buying plant (2000 or 3000) mayrepresented by an internal customer number. It is noted that if plant2000 always buys with Resale Minus regardless of the seller, ZICT may beset up at the ‘buyer’ level. However, if plant 2000 buys from USA viathe Cost-Plus method, we need to set-up ZICT=350 at ‘Buyer & Seller’level. The system may always look for the more specific record (by buyer& seller) first. If it cannot find this record, it may retrieve the moregeneric record (by buyer only). This ‘Condition technique/Accesssequence’ method may be deployed in many areas of SAP. 2) AResale-Factor (ZRPF) may be set up for the buying plant. (E.g. Minus5%). 3) The AIP price may be loaded in the Pricing Module. This may thenfeed pricing condition ZRFA. When plant 2000 (or 3000) buys from any ofthe A/Ts (or DCs from other regions), the system may recognize that thePricing-Method is “450”, and use pricing condition ZRFA.

EXAMPLE B

A US entity buys finished goods from Company X-Malaysia, Taiwan orPhilippines at Cost Plus Method. 1) ZICT may be set up as “350” for thebuying plant (Plant # 6000). The system may be customized to recognize“350” as inter-company price: Cost-Plus Method. 2) An A/T mark-up factor(ZATF) may be set up to represent the mark-up the A/T needs to make. 3)The Cost+price may be loaded in the Pricing Module. This may then feedpricing condition ZCWC. When USA (Plant 6000) buys from the A/T, thesystem may recognize that the price method is “350”, and thus usepricing condition ZCWC.

EXAMPLE C

A/T (Plant 4000) buys wafer from Tokyo W/F at Cost-plus method. 1) ZICTmay be set up as “250” for buying plant 4000. 2) A mark-up or cost plusfactor (ZEEE) may be set up for Tokyo W/F. 3) The Cost+AIP may be loadedin the Pricing Module. This may then feed pricing condition ZCWC. WhenA/T buys wafers from Tokyo W/F, system will use pricing condition ZCWC.

FIG. 18 is a flowchart illustrating a process for inter-company pricing.At block 1800, a transfer order may be created. At block 1802, adelivery note may be created. At block 1804, a delivery may be picked.At block 1806, a goods issue may be executed. At block 1808, an invoicemay be created and a price may be confirmed. At block 1810, a salesorder may be created and a shipping plant may be changed. At block 1812,a delivery note may be created. At block 1814, a delivery may be picked.At block 1816, a goods issue may be executed. At block 1820, invoicesmay be created and the price in intercompany invoice may be confirmed.

A key data may be organized as follows:

TABLE 3 Data Name America Asia Europe Japan Sales Org Buyer SellingPlant A/T Material

With the condition records setup, inter-company pricing between variousCompany X entities may be performed. The following steps represent ageneral system flow of the intercompany pricing. Condition records maybe created. Pricing condition records may be maintained in SAPtransaction code VK11. The condition record may be setup by selectingthe desired inter-company condition record, specifying an entity forwhich the condition record is created, and entering relevant pricingdata.

The following may demonstrate how to set up the condition recordsdescribed above for a semiconductor company. The following three scriptsor business scenarios may be applicable to all A/Ts which sell to someor all of their internal customers at the Cost Plus method. The ZICTmust be set to 250. Condition record ZICT may be created andinter-company price type 250, 350, 450 may be set for a buyer keycombination. In this script, the more general access sequence (keycombination) “Inter-company Pricing Method by Buyer” may be specified.The pricing methods may include:

250: Cost-Plus Prices computed: ZWFR*ZBBB. (For W/F Plant)

350: Cost-Plus Price computed: (ZCLM*ZAAA)+ZCHP+ZAOM (For A/T Plant)

450: Resale-Minus Price computed: ZAUP*ZRPF (For DC, Sales Org)

In setting up ZICT, it may be important to only use one of these valuesand only these values for the rate. Otherwise, SAP may not be able todetermine which pricing method to use. From a Create Condition screen,ZICT may be entered for the condition type and an enter key may bepressed. From the list of key combinations, the option of Inter-companyPricing Method may be selected by a Buyer. The valid From/to, Customer,Material and Rate fields may be completed. The Rate may be the pricingmethod and may be 250, 350, or 450 as described above. Condition RecordZICT Inter-company price type 250, 350 and 450 may be created.

For a Seller/Buyer Key Combination, the steps to create the conditionrecord may be the same as for the buyer level, except ‘Inter-companyPricing Method by Seller/Buyer/Material type’ may be chosen for the KeyCombination. Condition Record ZICT may be created. A wafer Fabricationcost-plus factor script may describe how to create a wafer costcondition record for a particular wafer fabrication. In the CreateCondition screen, ZWFF may be entered for the Condition Type. The ValidFrom, Valid To, Plant and Rate fields may be completed. The Rate may bedetermined as a markup percentage of 5%

The following two scripts may be applicable to all A/Ts which sell tosome or all of their internal customers at the Cost Plus method. TheZICT must be set to 350. ZICT inter-company price Type-250, 350 or 450may be created. The process may be repeated as described above, usingCondition type ZICT and Key Combination Inter-company Pricing Method byBuyer. ZATF A/T Cost Plus Factor (%) may be created. This script mayassume that the mark-up percentage (e.g. Cost Plus Factor) for a givenselling plant is the same for all products. ZATF may be entered as theCondition type and the Valid From/to, Plant and Rate fields may becompleted. The rate may be the percentage markup of a given good.

The following two scripts may apply to all DCs and Sales Organizationswhich may buy with the Resale-Minus method. The ZICT may be set to 450.ZICT Inter-co price types 250, 350 or 450 may be created. A ZRPF scriptmay be set for Resale Price Factor. The script may demonstrate how toset up a Resale Price Factor for a buying plant. In one configuration,the factor may be used to multiply the average trade invoice price ofthe same material to derive the inter-co price. The same factor may beused for the entire plant regardless of material. This may be maintainedby the Finance people in the buying plant who use ‘Resale-Minus method’.

It may be assumed in this script that a different state of finished(SOF) such as Turnkey versus Non-Turnkey are using the resale factor.Should the need arise to use a different factor for different SOF, thefactors may be set up in similar manner as the ‘VALUATION CATEGORY’function is turned on. The valuation Category may be a field in thematerial master use to differentiate SOF. ZRPF may be entered in theCreate Condition Screen and the user may click Enter. The Valid From/To,Customer and Rate fields may be filled in. The Customer may beestablished as the buying plant, and the Rate may be the factorindicating that, when this plant makes a purchase, the inter-companyprice is equal to the Average Invoice Price (ave.invoice.prices)multiplied by 0.5.

The following scripts may outline a process for creating and processingan inter-company order. The scripts may also show how to validate aprice/pricing procedure. Inter-company Transport Order may be created.The stock transport order may trigger the movement of material/goodsfrom one plant to another between company codes. A request is generatedthat may post a delivery requirement against the supplying plant. Whenviewing the Stock Overview, the On Order quantity for the requestingplant may be incremented. The StckTrsptOrdRel quantity may beincremented for the supplying plant.

A delivery note may be created for a transport order, such as inter andintra-company. The Shipping point field may be completed and thecheckbox marked for Stork Transports under ‘Documents to be selected’. Adisp. del. due list button may be clicked. A box beside the “Review &Select the Stock Transport Orders for Delivery Processing” line may bechecked. The Deliveries button may be clicked to view the order anddelivery numbers. To pick a delivery, the delivery number may be enteredand the Picking button clicked. The quantity to be picked may be enteredand the save button clicked. To execute a goods issue for a singledelivery, the delivery number may be entered and the Post goods issuebutton clicked. To create an Interco Billing first for a CrossDockshipment, the delivery note number may be entered for the crossdocksales order and the Default Data button clicked. Billing type IV may beselected and the continue button clicked, then the script may beExecuted. When a user reaches the Inter-company Billing (IV), anoverview of Billing Items screen may be created, and the user may selecta line item and click on the <Pricing> button. The user may then be ableto check the pricing calculation in the Inter-company Billing (IV)Create, such as via the Item Conditions screen.

The following scenario may occur for semiconductor companies postinginter-company invoices when creating a sales order that crosses companycodes. SAP may be configured to create two invoices for internationalorders: one invoice for the customer, and one inter-company invoice thatmay be sent to the sales organization/plant that is based in thecustomer's region.

The process for changing the order may be as follows: An order may becreated. A delivery plant may be changed at item level. The Order fieldmay be filled with the order number and the user may click Enter. Theuser may select the line that the user wants to change and selectGoto=>Item=>Shipping. The user may change the Plant by overriding thefield with any plant number the user needs. The user may change theShipping Point field to reflect the value set in the Plant field. Theuser may change the Route and Storage Location if needed. A deliverynote may be created and a delivery picked. The user may execute a goodsissue for a single delivery. The post goods issue transaction may beperformed after a delivery is completely prepared for shipping. Thistransaction may update the inventory and initialize the requiredfinancial postings.

The user may create a single invoice for trade sales and aninter-company invoice using the same delivery note. The user may displayand verify that two invoices are created in direct ship (trade &Inter-Co). The user may complete the Order field and selectEnvironment=>Document Flow. The user may select the Inter-companyInvoice line and click on the Display Document button. The user mayselect the desired item and click the Pricing button. The user may checkthe price calculated and the conditions used.

Although the present specification describes components and functionsthat may be implemented in particular embodiments with reference toparticular standards and protocols, the invention is not limited to suchstandards and protocols. For example, standards for Internet and otherpacket switched network transmission (e.g., TCP/IP, UDP/IP, HTML, HTTP)represent examples of the state of the art. Such standards areperiodically superseded by faster or more efficient equivalents havingessentially the same functions. Accordingly, replacement standards andprotocols having the same or similar functions as those disclosed hereinare considered equivalents thereof.

The illustrations of the embodiments described herein are intended toprovide a general understanding of the structure of the variousembodiments. The illustrations are not intended to serve as a completedescription of all of the elements and features of apparatus and systemsthat utilize the structures or methods described herein. Many otherembodiments may be apparent upon reviewing the disclosure. Otherembodiments may be utilized and derived from the disclosure, such thatstructural and logical substitutions and changes may be made withoutdeparting from the scope of the disclosure. Additionally, theillustrations are merely representational and may not be drawn to scale.Certain proportions within the illustrations may be exaggerated, whileother proportions may be minimized. Accordingly, the disclosure and thefigures are to be regarded as illustrative rather than restrictive.

Although specific embodiments have been illustrated and describedherein, it should be appreciated that any subsequent arrangementdesigned to achieve the same or similar purpose may be substituted forthe specific embodiments shown. This disclosure is intended to cover anyand all subsequent adaptations or variations of various embodiments.Combinations of the above embodiments, and other embodiments notspecifically described herein, is apparent to those of skill in the artupon reviewing the description.

The above disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover all suchmodifications, enhancements, and other embodiments, which fall withinthe true spirit and scope of the present invention. Thus, to the maximumextent allowed by law, the scope of the present invention is to bedetermined by the broadest permissible interpretation of the followingclaims and their equivalents, and shall not be restricted or limited bythe foregoing detailed description.

1. A method for setting up a credit check of a customer, the methodcomprising: setting a customer risk category; reviewing credit based onthe risk category; setting a customer hierarchy; and assigning customercredit limit to the customer based on the reviewed credit and thecustomer hierarchy.
 2. The method of claim 1 further comprising checkingwhether a delivery date is within a determined horizon.
 3. The method ofclaim 2 wherein assigning the customer credit limit is further based onwhether the delivery date is within the determined horizon.
 4. Themethod of claim 1 further comprising assigning a next credit reviewdate.
 5. The method of claim 4 further comprising disallowing creationof an order if the next credit review date is not assigned.
 6. Themethod of claim 4 further comprising disallowing creation of a deliverydate if the next create review date is not assigned.
 7. The method ofclaim 4 wherein an order delivery is disallowed if a credit is notreviewed before the next credit review date is passed.
 8. The method ofclaim 1 wherein the customer hierarchy comprises a world wide customer,a central office customer and a sold-to customer.
 9. The method of claim8 wherein an order delivery is disallowed unless within a credit limitof the sold-to customer and a credit limit of a central office customerrelated to the sold-to customer.
 10. The method of claim 8 wherein theassigned credit limit is managed collectively if the sold-to customershares a payer with other sold-to customers.
 11. A system for setting upa credit check of a customer, comprising: a customer risk category; acredit based on the risk category; a customer hierarchy for a pluralityof customers; and a customer credit limit being assigned to the customerbased on the reviewed credit and the customer hierarchy.
 12. The systemof claim 11 further comprising a delivery date and a determined credithorizon.
 13. The system of claim 12 wherein the customer credit limit isfurther based on whether the delivery date is within the determinedcredit horizon.
 14. The system of claim 11 further comprising a nextcredit review date.
 15. The system of claim 14 further comprising anorder creation is not allowed if the next credit review date is notassigned.
 16. The system of claim 14 further comprising a delivery dateis not allowed if the next create review date is not assigned.
 17. Thesystem of claim 14 wherein an order delivery is not allowed if a creditis not reviewed before the next credit review date is passed.
 18. Thesystem of claim 11 wherein the customer hierarchy comprises a world widecustomer, a central office customer and a sold-to customer.
 19. Thesystem of claim 18 wherein an order delivery is disallowed unless withina credit limit of the sold-to customer and a credit limit of a centraloffice customer related to the sold-to customer.
 20. The system of claim18 wherein the assigned credit limit is managed collectively if thesold-to customer shares a payer with other sold-to customers.